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

List:       kfm-devel
Subject:    Re: kdelibs/khtml/rendering
From:       Peter Kelly <pmk () post ! com>
Date:       2001-12-29 3:19:06
[Download RAW message or body]

On Fri, 28 Dec 2001, Dirk Mueller wrote:

> On Fre, 28 Dez 2001, Peter Kelly wrote:
> 
> > Changed RenderWidget so that the widgets are drawn as part of the normal
> > rendering process, instead of directly by qt, and pass on events ourselves
> > from the DOM event dispatching routines. This means
> 
> Are you sure that you can filter out the paint events in all cases ?
> 
> This solution was discussed already before, and afaik the consensus was that 
> it is not possible to trick the X server, it will send repaint events which 
> we can not control (think about embedded windows from applets). 

We can filter out all of the events sent by qt... but I found that the area 
under the widgets is still getting painted (an area set up by X perhaps?). 
I suspect we can prevent this by using the WPaintUnclipped flag on 
the KHTMLView's viewport, but alas QScrollView provides no way to do this.

I tried having the widget set as hidden, and showing it just when I 
wanted it painted, and also having the widget shown but placed outside of 
the viewing area but both caused problems as widgets were not behaving 
as expected when this was the case.

I've come to the conclusion that the only solution is to actually have the 
widget in place and visible but to filter paint events.... I believe it is 
just a matter of being able to paint on top of the widget area 
(WPaintUnclipped).


> 
> Also I'm unsure if drawing to pixmaps is going to be fast for framesets. 
> 
> 
> Dirk
> 

Good point. I'll enable direct repaints for frames.


-- 
Peter Kelly
pmk@post.com

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