Re: Reporter flooded with colourtrans message
- From: Martin <News@xxxxxxxxxxxxxxxxxx>
- Date: Sat, 31 Dec 2005 13:06:51 +0000 (GMT)
In article <4de1a6d211steve.pampling@xxxxxxxxxxxxx>,
Steven Pampling <steve.pampling@xxxxxxxxxxxxx> wrote:
> In article <4de1723925News@xxxxxxxxxxxxxxxxxx>, Martin
> <News@xxxxxxxxxxxxxxxxxx> wrote:
> > Worse still, the Command and SWI are executed many times when a window
> > is moved over the background Pinboard image.
> > Even worse, they are accompanied by two OS_Memory Extends for around
> > 60 additional bytes to one memory area (now at 680k and counting) ...
> > and I have yet to see a Release of the storage! (This happens even
> > with a Sprite background).
> I can reproduce the memory loss/leak in 4k chunks on a RPC but only
> when MiniDisc is loaded. If you have it tracked down to something
> simple and OS related then MiniDisc would seem to be merely increasing
> the size of the problem.
> It doesn't require a backdrop loaded for the problem to occur.
Did some more experiments here, and initial results seem to be ...
With RO4.39
If there is a displayed JPEG (in a window or the Pinboard backdrop) then
if something is moved which exposes more of the JPEG, then ColourTrans
Claims and Frees about 1k. A window drag creates lots of these!
No RMEnsures of ColourTrans were observed.
This is not affected by MiniDisc running.
With RO5.10
If there is a displayed JPEG (in a window) then if something is moved
which exposes more of the JPEG, then WindowManager Claims and Frees about
260 bytes. A window drag creates lots of these!
This does not seem to apply to a JPEG Pinboard background.
Lots of RMEnsures of ColourTrans were observed if more of a JPEG
background was revealed.
However, if MiniDisc is running, then any movement which exposes more of
the Pinboard background (whether JPEG or Sprite) causes WindowManager to
Extend an area by about 60 bytes. This area seems persistant - I have not
seen it freed, and it just gets bigger (I have seen over 10/second!).
This supected memory leak is easily seen in the Tasks display of 'Free in
Module Area'.
These experiments may not be conclusive, but I think these observed
differences between the two 'latest' versions of RISC OS illustrate how
much they have diverged under the covers. For example, I suspect ROL have
spent some considerable time in reducing the storage thrashing which used
to occur (eg each display of a menu or submenu) and still does with RO5.
It also illustrates how applications can behave differently under the two
branches, causing a continuing nightmare for application developers.
My fervent wish for 2006 is that we see some convergence bewteen the two
branches of RISC OS. The RISC OS community (suppliers, software
developers and users) CANNOT afford to continue to support two branches
of the OS.
PLEASE can we have some sense in 2006?
Martin
--
Martin Avison
Note that emails to News@ will be junked. Use Martin instead of News
.
- Follow-Ups:
- Re: Reporter flooded with colourtrans message
- From: druck
- Re: Reporter flooded with colourtrans message
- References:
- Reporter flooded with colourtrans message
- From: John Rickman
- Re: Reporter flooded with colourtrans message
- From: David Pitt
- Re: Reporter flooded with colourtrans message
- From: Martin
- Reporter flooded with colourtrans message
- Prev by Date: Re: "Device not ready" (CDBurn)
- Next by Date: Re: "Device not ready" (CDBurn)
- Previous by thread: Re: Reporter flooded with colourtrans message
- Next by thread: Re: Reporter flooded with colourtrans message
- Index(es):
Relevant Pages
|