Re: Getting the viewport location/size

[monkeyiq dingoblue net au]

On 24 Mar 2001 11:53:35 -0500, Havoc Pennington wrote:

> 

> monkeyiq dingoblue net au writes:

> > I see the gtk_viewport_get_Xadjustment() calls, but they would only solve the

> > x,y part of the problem from what I can put together.

> > Is there an easy way to get the x,y,w,h of the currently viewed part of a

> > GtkViewPort?

> 

> I think gdk_window_get_size (viewport->view_window) probably works. 

> 

> However, this is normally handled by doing your redraw in response to

> an expose event which has the redraw area in it.

> 

> Getting the current area is inherently incorrect code, because of a

> race condition:

> 

>  get_area ();

>  /* area may change here... */

>  draw_to_area ();

> 

> So if you need to redraw the area because of a change in your

> program's data, rather than an expose, typically you would redraw the

> entire area that was affected by the data change, not just the

> viewport bit. X will automatically optimize by clipping to the visible

> part of the window, so the only cost here is sending the X request

> packets, actual drawing won't happen outside the window.
The problem here is that the widget is gevas (the Gtk+ wrapper for evas) and so when I am drawing,
I really call evas_render() and unless I use evas_add_obscured_rect() to clip out sections that I am
not interested in drawing then the evas_render() call will render the entire canvas. So here there may
be many layers of alpha blended images etc to render which slows things down if imlib2 has to software
alpha blend all these images that are never seen.

Although it seems to be a direct trade off, either live with the race condition you mentioned above, or
you have to live with knowing that the whole gevas widget will be rendered each time you queue a
gevas draw update (from the gevas API).

Although I can't see much that would change line (A) that would be a problem.

get_area ();
/* (A) area may change here... */

draw_to_area ();
ie. 
1. If the viewport moves 
2. If the viewport resizes
3. Some window that is overlapping gevas moves 

For both 1,2 & 3 then gtk+ should call paint() or expose(), the net effect being that my nasty hack to
render the get_area() section only will work and then gtk+ will effect a change and call another function
in gevas to update the widget display to the new size / section.

> Also, you can

> optimize by using gtk_widget_queue_draw() to trigger the redraw

> instead of doing it immediately, then multiple redraws in short

> sequence will get compressed into one.
Thanks for this tip, I sort of went in copying other code at the start of gevas and thus copied a 
idle handler way for doing the above optimization. I'll move gevas over to gtk_widget_queue_draw()
soon :)
> 

> Havoc

> 

>