Chris Toshok | 2 Oct 03:11 2007

Re: [PATCH] Invalidate non visible areas when scrolling

[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.

Chris

On Mon, 2007-09-24 at 14:27 -0500, Carlos Alberto Cortez wrote:
> Hey, 
> 
> While trying to fox bug #324513, I notice that trying to scroll a
> control, which has bigger bounds than any of its Parents controls,
> 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
(Continue reading)

Eric Albright | 2 Oct 03:45 2007

Re: XIM support

Miguel de Icaza wrote:
> Hello John,
>
>   
>> In the next 4 months, we’ll reach a point where our SWF/MWF app, which
>> runs on the OLPC, will have to be re-written in GTK or QT for lack of
>> custom-keyboard ability
>> ( https://bugzilla.novell.com/show_bug.cgi?id=320988 ).  Being a
>> Windows shop, we don’t have the first clue how to go about adding this
>> ourselves.
>>     
>
> When is your hard deadline for this, and what kind of support are you
> looking for?
>
> The XIM as far as I know is used for entering international characters
> that might not be present on the keyboard (beyond the basic X setup).
> Do you need something beyond the base X setup?
>
>   
Our clients switch between many input languages (at least two sometimes 
as many as four). These languages are a mixture of major languages (like 
English, Chinese, French, and Thai) and minority languages, which often 
times have minor variations from the national language and require 
custom keyboard support. KMFL (http://kmfl.sourceforge.net/) addresses 
this need for custom keyboard support and uses SCIM.
> Could you describe what is the particular scenario, there might be a
> subset of the bug that can be implemented.
>
>   
(Continue reading)

Carlos Alberto Cortez | 2 Oct 05:47 2007
Picon

Re: [PATCH] Invalidate non visible areas when scrolling


Hey

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 value.

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.

Carlos.

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.

Chris

On Mon, 2007-09-24 at 14:27 -0500, Carlos Alberto Cortez wrote:
> Hey,
>
> While trying to fox bug #324513, I notice that trying to scroll a
> control, which has bigger bounds than any of its Parents controls,
> 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
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Chris Toshok | 2 Oct 07:03 2007

Re: [PATCH] Invalidate non visible areas when scrolling

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).

Chris

On Mon, 2007-10-01 at 22:47 -0500, Carlos Alberto Cortez wrote:
> 
> Hey
> 
> 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
> value. 
> 
> 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.
> 
> Carlos.
> 
> 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.
>         
>         Chris
>         
>         On Mon, 2007-09-24 at 14:27 -0500, Carlos Alberto Cortez
>         wrote:
>         > Hey,
>         >
>         > While trying to fox bug #324513, I notice that trying to
>         scroll a
>         > control, which has bigger bounds than any of its Parents
>         controls, 
>         > 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
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Richard Santaella | 2 Oct 13:55 2007
Picon

Unsuscribe



--
Richard Santaella
_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Ernesto | 3 Oct 18:30 2007
Picon

Need help to understand WinForms code

Hi,

I'm working on bug #328019

The problem seems to be that MdiParent is changed during MDI children's 
load event (although it'is set to the same parent again, MdiParent.set 
does it's thing anyway). .NET allows a MdiParent change during the load 
event of a children even to a different parent.

The simplified problem is:

MdiParent.set {
    ...
    if(value != null) {
       ...
        if (IsHandleCreated)
            RecreateHandle ();
    }
}

Now RecreateHandle() will cause a chain reaction of handle destruction 
(and recreation). The question is, why must the handle be recreated (via 
DestroyHandle by the way) when changing parents?

Of course, the test app for this bug will pass if you comment 
RecreateHandle ();

Regards,
Ernesto

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Ernesto | 3 Oct 18:31 2007
Picon

Need help to understand WinForms code

Hi,

I'm working on bug #328019

The problem seems to be that MdiParent is changed during MDI children's 
load event (although it'is set to the same parent again, MdiParent.set 
does it's thing anyway). .NET allows a MdiParent change during the load 
event of a children even to a different parent.

The simplified problem is:

MdiParent.set {
    ...
    if(value != null) {
       ...
        if (IsHandleCreated)
            RecreateHandle ();
    }
}

Now RecreateHandle() will cause a chain reaction of handle destruction 
(and recreation). The question is, why must the handle be recreated (via 
DestroyHandle by the way) when changing parents?

Of course, the test app for this bug will pass if you comment 
RecreateHandle ();

Regards,
Ernesto

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Ernesto | 3 Oct 18:33 2007
Picon

Need help to understand WinForms code

Hi,

I'm working on bug #328019

The problem seems to be that MdiParent is changed during MDI children's 
load event (although it'is set to the same parent again, MdiParent.set 
does it's thing anyway). .NET allows a MdiParent change during the load 
event of a children even to a different parent.

The simplified problem is:

MdiParent.set {
    ...
    if(value != null) {
       ...
        if (IsHandleCreated)
            RecreateHandle ();
    }
}

Now RecreateHandle() will cause a chain reaction of handle destruction 
(and recreation). The question is, why must the handle be recreated (via 
DestroyHandle by the way) when changing parents?

Of course, the test app for this bug will pass if you comment 
RecreateHandle ();

Regards,
Ernesto

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Ernesto | 3 Oct 18:32 2007
Picon

Need help to understand WinForms code

Hi,

I'm working on bug #328019

The problem seems to be that MdiParent is changed during MDI children's 
load event (although it'is set to the same parent again, MdiParent.set 
does it's thing anyway). .NET allows a MdiParent change during the load 
event of a children even to a different parent.

The simplified problem is:

MdiParent.set {
    ...
    if(value != null) {
       ...
        if (IsHandleCreated)
            RecreateHandle ();
    }
}

Now RecreateHandle() will cause a chain reaction of handle destruction 
(and recreation). The question is, why must the handle be recreated (via 
DestroyHandle by the way) when changing parents?

Of course, the test app for this bug will pass if you comment 
RecreateHandle ();

Regards,
Ernesto

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Dan Maltes | 4 Oct 03:15 2007

Releasing the Source Code for the .NET Framework Libraries

Any thoughts on how Scott Guthries announcement will influence future Mono Winform releases? 

http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx

-Dan Maltes

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Gmane