Re: NSView draw order messed up

[Lundberg, Johannes]

Yes, we should have to setNeedsDisplay to cause it to redraw. This is no different. However, is it ok to need to have code like this?

[view setNeedsDisplay:YES];

view.frame = newFrame;
[view setNeedsDisplay:YES];

To compare with OS X or iOS you only need
view.frame = newFrame;
[view setNeedsDisplay:YES];

I will try to find some more info on how this is implemented in Cocoa.

--

Johannes Lundberg

Project leader and lead developer of Mirama OS (previously Viking OS)

BRILLIANTSERVICE CO., LTD.

My blog

Mirama homepage blog

Company homepage

On Fri, Oct 4, 2013 at 3:06 PM, Fred Kiefer <fredkiefer@gmx.de> wrote:

Sorry, the problem here is that GNUstep follows the specification. There it states:

"This method, in setting the frame rectangle, repositions and resizes the receiver within the coordinate system of its superview. It neither redisplays the receiver nor marks it as needing display. You must do this yourself with display orsetNeedsDisplay:."

Now we will need to assert that the actual implementation on Cocoa behaves differently before we change our code.

Fred

On the road

Am 04.10.2013 um 02:46 schrieb "Lundberg, Johannes" <johannes@brilliantservice.co.jp>:

Another things I noticed is that when moving or scaling a NSView by changing the frame you have to call [view setNeedsDisplay:YES] before and after changing the frame (this is not needed on OSX/iOS). If you only call setNeedsDisplay after changing the frame the old frame is not redrawn and causes a trail of remaining pixels where the view has been. This could be fixed by adding functionality to setFrame, couldn't it? How if we keep the old frame in a private variable and redraw both frames when call to redraw is made?

--

Johannes Lundberg

Project leader and lead developer of Mirama OS (previously Viking OS)

BRILLIANTSERVICE CO., LTD.

My blog

Mirama homepage blog

Company homepage

On Thu, Oct 3, 2013 at 8:20 PM, Matt Rice <ratmice@gmail.com> wrote:

On Wed, Oct 2, 2013 at 5:51 PM, Lundberg, Johannes
<johannes@brilliantservice.co.jp> wrote:
> Thanks all for your replies.
>
> Matt is correct. A quick test with this code after subviews has gotten new
> values (calculated with some analytic formula)
>
>     for each subview
>     {
>         subview.frame = NSMakeRect((int)subview.frame.origin.x,
> (int)subview.frame.origin.y, (int)subview.frame.size.width,
> (int)subview.frame.size.height);
>     }
>
> fixes the problem.

Unfortunate because this problem is likely unapparent for
non-overlapping views, causing unnecessary redraws.

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep