Re: NSView draw order messed up

[Lundberg, Johannes]

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.