Re: [PATCH] Invalidate non visible areas when scrolling
Chris Toshok <toshok <at> ximian.com>
2007-10-02 05:03:45 GMT
It does, but I don't think we need to add tracking of invalid areas
which are offscreen - the whole point of the invalid area tracking is to
track things that need to be repainted *because* they're visible. If
it's offscreen, we shouldn't need to do anything that complicates it.
It seems like a better solution to just figure in the clipping by parent
forms into the pseudo clipping we already do. The scroll code takes
into account that a child's view can be larger than the child (the
AddExpose calls). It shouldn't be too hard to figure out the *actual*
visible rectangle of that child, if it's not already done someplace, and
make the AddExpose calls take that into account, without the additional
calculation (and invalidation, which will just be ignored anyway).
On Mon, 2007-10-01 at 22:47 -0500, Carlos Alberto Cortez wrote:
> Basically we are scrolling a control and right now we are assuming
> that the control is completely visible.
> For example: Imagine we have a ListView in a form, and that the Form
> size is minor than the ListView - specifically the ListView control
> has a bigger height than the form:
> | ----------- | <- This if the form
> | | | |
> |_ | ____ | __|
> | |
> |_____ | <- This is the ListView (with bigger Height)
> Now, from XplatUIX1.ScrollWindow we get a Rectangle to scroll, as well
> as XAmount/YAmount variables. So, when we have more items than the
> visible area of the ListView can contain, we will need to scroll, and
> we pass the entire Rectangle to ScrollWindow, as well as a YAmount
> Now, ScrollWindow copies some area when scrolling, and invalidates the
> 'new' visible area. So if we are scrolling our ListView (to see items
> below) we have a call such:
> ScrollWindow (handle, lv.ClientRectangle , yamount, 0, false);
> It tries to copy the area -
lv.ClientRectangle- to a new position below
> (say, 48 pixels), and the 48 pixels at the top are invalidated in
> ListView. So, as it can be seen, our ScrollWindow method does think
> that the scrolled area is visible. BUT, as the ListView sample shows,
> it can happen that the control is not actually visible (in the sample,
> the bottom area of the ListView is NOT visible).
> This is why we need to invalidate the areas that we are scrolling
> *and* were not previously visible.
> I hope this explanation helps.
> 2007/10/1, Chris Toshok < toshok <at> ximian.com>:
> [d'oh. sent this already from my hungry.com address, but I
> think the
> list software will block it since I'm subcribed <at> ximian.com..]
> I'm confused. Why are we invalidating non-visible parts of
> the screen?
> They're not visible.
> On Mon, 2007-09-24 at 14:27 -0500, Carlos Alberto Cortez
> > Hey,
> > While trying to fox bug #324513, I notice that trying to
> scroll a
> > control, which has bigger bounds than any of its Parents
> > shows some drawing issues.
> > Example: you have a VScrollBar with Height > than its
> contaning form:
> > __________
> > | | | <- This is the form (Parent)
> > |____|_____|
> > | <- This is the scrollbar
> > This is because when we try to scroll a windows, we copy
> some area of
> > it and invalidate the 'new visible' one.
> > But we assume that the entire control is visible (that all
> its Bounds
> > are painted and available to scroll). But it's not the case
> in this
> > case, where the VScrollBar is not entirely visible,
> > because it's parents Bounds don't contain it.
> > The attached patch tries to detect all the non-visible
> regions of a
> > control (top, bottom, right, left) and then check if whe are
> trying to
> > scroll part of the non visible area,
> > which then is invalidated.
> > Carlos.
> > _______________________________________________
> > Mono-winforms-list
> maillist - Mono-winforms-list <at> lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Mono-winforms-list maillist - Mono-winforms-list <at> lists.ximian.com