[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] [9] Review Request: JDK-8029250 [macosx] There is no tray icon shown in the sys
From:       Jim Graham <james.graham () oracle ! com>
Date:       2013-12-19 0:12:23
Message-ID: 52B239E7.1000408 () oracle ! com
[Download RAW message or body]

Also, currently we render animated GIFs by continually decoding them, 
which is a CPU waste, but it does save a little on memory.  That design 
also complicates this MediaTracker issue since the tracking and the 
loading and the frames are all equated under the covers in a way that 
makes it hard for MT to say "I'm OK now, but don't stop loading on my 
account" while at the same time allowing our ImageLoader threads to have 
some metric that lets them know when to stop decoding the GIF.  The MT 
also can't distinguish between frames that happen while still loading 
the file and those that happen after the file is loaded and are just 
repeating.

Given the relatively modest savings in memory, I think it might be 
better to find a way to decode every frame once and keep it around in 
the ToolkitImage, and then use just a simple "time to render the next 
frame" mechanism to periodically call the imageUpdate methods and switch 
to the next decoded frame.  If we moved to such a system, then this 
particular bug may have an alternate (and possibly easier) way to fix it 
since it wouldn't be side effecting the loading of images to trigger 
frame repainting and MT notices.  But...

Another complication is that animated GIFs send FRAMEBITS on every frame 
even if it is a repeat until the properties say that the animation is 
over and only then do they send ALLBITS.  As a result, MT has a choice 
between ending its interest at the first frame (as it currently does 
which causes us to dispose() internally), keeping interest forever which 
might turn into a long term CPU leak and means it will never answer 
"fully loaded now", or perhaps guessing at the number of frames?  There 
is no good answer there for MT.  If we had a way to communicate that the 
multi-frame image had loaded all of its frames and was now "fully 
loaded" even though it was still animating, then MT could use that 
instead - but that would involve new ImageObserver API - perhaps a new 
bit meaning "ALLFRAMESLOADED" that can get tacked on to FRAMEBITS, but 
doesn't mean "ALLBITS" (since ALLBITS currently means the animation has 
reached its end).  Even then, how does a MT know the difference between 
an image loader that supports this convention and one that doesn't? 
Perhaps "FRAMEBITS | NOTALLFRAMESLOADED" could mean the opposite (and 
would only be used for cases of a limited number of frames like an 
animated GIF, not cases where a custom Producer might produce an 
infinite number of frames).  MT would then unregister on the first 
FRAMEBITS that did not have NOTALLFRAMESLOADED or on the first ALLBITS?

(Note to self "NOTALLFRAMESLOADED" is a bad name for a new flag...)

			...jim

On 12/18/13 2:21 PM, Jim Graham wrote:
> Hi Petr,
>
> Have you verified that if someone draws an animated GIF and then later
> returns false from the observer that the associated ImageLoader thread
> goes away?  I think the dispose() method had a side effect of allowing
> the thread to go away and if you don't call it then the ImageLoader
> threads that serve the displayers of an animated GIF may run forever
> once triggered...
>
>              ...jim
>
> On 12/18/13 6:01 AM, Petr Pchelko wrote:
>> Hello, AWT and 2D teams.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8029250
>> It also resolves the issue:
>> https://bugs.openjdk.java.net/browse/JDK-6740321
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8029250/webrev/
>>
>> The problem:
>> In AWT we use a MediaTracker to wait for the tray icon loading.
>> However, if the TrayIcon is an animated gif the following happen:
>> The MediaTracker installs an ImageObserver to an image and starts
>> loading. After the first frame is loaded (and it's really all we need)
>> the media tracker correctly exits and removes it's ImageObserver. And
>> as it's the only observer the checkConsumption is called in an
>> ImageRepresentation. As the availinfo is just FRAMEBITS the
>> successfully loaded frame was immediately disposed and AWT failed
>> to draw a tray icon.
>>
>> With best regards. Petr.
>>
[prev in list] [next in list] [prev in thread] [next in thread]