ok, I've just looked into the code.. you had a great idea with the hook,
only problem is "it's not good enough".. indeed, that's what's making our
CPU so high!
let me resume what you do
for each gif, you have
a timer that launches after each Xms (where X is the delay between each
frame in the gif)
we call Tk_ImageChanged so that Tk redraws all images in their
respective drawable component
We get our hook called and we copy the new image's
content to the image
a new display is called, so the hook is again called, this time we
display it, updating all images
we continue from our hook, and we update AGAIN,
redisplaying TWICE
we set a new timer
end
end
you see the problem ? the problem is that we draw the image twice, and
even if the image didn't change, we still notify Tk that it changes, so it
will update it (you specify a new size, so it resizes it and makes
adjustments to the pixel pointer, probably) and it will also probably
rewrite the image in memory even if it's not displayed (you specify a new
size for the image in the imagechanged.. imagine that it makes the image
do a SetSize.. which in turn will copy the pixel pointer to a new buffer,
do some algorithm to crop it, then recopy it doing a PhotoPutBlock... )
not sure about the last thing, maybe totally false.. but it may be
something.. in any case, we force a double write to the screen's buffer..
this is what takes so much CPU!
ok now, this is what If ound.. spent some time looking at tkImage.c code
and look here :
struct Image *image = Tk_GetImage(Tk_MainWindow(),
Tk_Display(Tk_MainWindow(), imageName, NoDispProc, NULL);
struct Image *currentImage = image;
while(currentImage != NULL) {
currentImage = image->nextPtr;
if (currentImage == image)
continue;
// Need to check for more than just IsMapped.. because text widget will
be mapped
// but the specific position of the image in the text might not be mapped
to the screen...
if (Tk_IsMapped(currentImage->tkwin)) {
UpdateAnimatedGifToNextFrame(...);
break;
}
}
// IMPORTANT
Tk_FreeImage(image);
We wouldn't need the hook anymore...
look at tkImage.c, it's fairly easy to understand.. and we might find an
alternate solution (although the one I just proposed is not the best one I
think)
Thanks.
KaKaRoTo
On Fri, 27 Jan 2006 15:38:44 -0500, Youness Alaoui
<[EMAIL PROTECTED]> wrote:
hoho, sorry, that wasn't clear.. if you want to explain in french, I'd
vote for it (or in PM if you prefer)..
I'll look at the code and try to understand what you meant, or I'll
simply reread this once I' ma bit more awaken...
I'll explain in one line (yes, possible:P) what I think should be :
we get the hook called to display, we check to make sure we have
something to draw, we set a value that tells us if we need to draw or
not... hummm forget it.. if we don't update the image, or if the window
doesn't move or anything (image space not dirty) we won't get a draw
notification...yep, that's a tricky one!
I'll do some research (after retrying to read your mail) and let you
know what I think
KKRT
On Fri, 27 Jan 2006 14:52:59 -0500, Le Philousophe - Phil
<[EMAIL PROTECTED]> wrote:
Well...
I will try to explain me clearly... If it isn't clear please notify
me...
The main trouble comes from the fact that we can't know if an image is
displayed or not. So actually, at each frame, we notify Tk that the
image has
changed and Tk will propagate the information to all widgets linked to
the
image. Then, each widget will check if the image is displayed or not
and if
it is displayed it will ask us to redraw it. And just before we redraw
it, we
copy our internal buffer to the image and we ask to Tk to draw it (don't
forget we act as a hook).
Now, I just think about that, but not sure it will be good since it can
raise
inconsistencies, in place of change the image just before we warn Tk we
changed it, we can increment when we draw itso that when the image is
hidden
it stops and resumes only when we redisplay it. Now the inconsistency,
imagine the same image is displayed at two places in same time, one is
showed
and one is hidden, if we display the hidden one, it will show us a
frame. We
rehide it wait a little and show it again, we won't have the animation
where
we leave it ! So I prefer it does the same thing everywhere and
everytime :
it continues the animation in the background.
Phil
Le Thursday 26 January 2006 23:28, Youness Alaoui a écrit :
anigifs take too much CPU, is it normal ? I though it used less cpu
than
when Phil added his fix (but uses less CPU on other machines..)
Also, even if the image is not in screen, it gets udpated.. I think
there
is a logic problem in your code, probably a small one, but you might
want
to check (I noticed not only because of high CPU if chat window is
opened
even if no smileys shown).. I just saw Alvaro's DP (animated gif), I
put
the tooltip, I see the beginning of the animation, I remove the mouse
(no
tooltip), wait a few secs, then put back the tooltip, the animation is
at
the end, while it should have just continued from the last moment I
removed the tooltip (I have no window opened with Alvaro, so there was
nowhere else it could have been showing itself...)
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Amsn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amsn-devel
--
KaKaRoTo
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Amsn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amsn-devel
