Re: [gtk-list] Code escape: Gzilla 0.01

[Myslik Vladimir student 4_96_97 k336 <xmyslik sun felk cvut cz>]

------------------------------------------------------------------
 Vladimir Myslik  
(if you experience delivery problems replying my mail, try the addresses below)
mailto:xmyslik@cslab.felk.cvut.cz , mailto:xmyslik@cs.felk.cvut.cz
http://cs.felk.cvut.cz/~xmyslik/
On Thu, 15 May 1997, Raph Levien wrote:

>    After having gotten this far, I'm having mixed feelings. In the fully
> modular widget design, gtk+ simply cannot guarantee me the performance I
> feel is necessary for a really cool Web browser. The main problem I'm
> running up against is size changes. In _addition_ to the problems I
> mentioned a few days ago (that come into play when you put a lot of
> widgets into a gtk_page), doing a gdk_window_move_resize is causing the
> entire window to be blanked. I _think_ it's the underlying X server
> (XFree86 3.2 on an S3 in my case) that's doing this, but I'm not
> positive. Either way, it's unacceptable - instead of smooth display when
> a page downloads, it flickers like <BLINK> on methamphetamines. Not
> good.
> 
>    I do see a few ways around this - most notably, I could suck the
> scrollbar into the gtk_page widget, make gtk_page itself a fixed size
> window, and handle all of the size changes and scrolling inside gtk_page
> itself. But this has two drawbacks - first, I lose modularity within the
> gtk+ framework, and second, I have to repaint the entire window on every
> scroll. The way it works now, scrolling causes most of the window to be
> preserved, with an expose event for the little bit that scrolled into
> visibility. I'm pretty sure this is the approach that Netscape uses, by
> the way.
> 
>    Another possiblility is the way qweb does it - throttle the rate of
> window resize calls. This way, the flashing is reduced (so it now looks
> like <BLINK> on barbiturates) but not entirely eliminated. Also, updates
> don't appear to happen as quickly.

I think it would be very nice to have library support (gtk) for such. If 
the gtk maarked the widgets/objects whenever it needed to redraw them but 
didn't do it and made it 10 ms later for all of them (the 
changed/redrawed ones) this would prevent much of the havoc but wasn't 
noticeable (actually it would be even faster than redrawing on every 
library call). This may already have some support in the library (Ithink 
I've read on gtk-list some postings). The only problem is with the 
scheduled redraw....

Maybe It's already there or I'm missing something... I'm a newbie to gtk.

			Vladimir

P.S. my problem is with the preview objects, I need a second thread to 
fill them as soon as it computes them, besides the main thread doing display.


> 

>    If gzilla is to be used primarily to browse local files (e.g. as the
> Gimp's help browser), then the window flashing problem is not nearly so
> severe.
> 
>    So please take a look and let me know what you think. If you have any
> ideas about the window flashing problem, I'd certainly like to hear
> them.
>