Re: NSView draw order messed up

[Lundberg, Johannes]

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.

I also bumped into a similar problem on iOS. After calculating new values for frames and not rounding them off properly fonts in UILabel subviews can become a bit blurry.

Regarding the draw order. Of course the draw order should be in the order the subviews are ordered in subviews array.
Why else is there a method for inserting subviews at different depths?

 Even if it's not documented it's the natural way to do it. It seems that this is also the case so no point arguing about it :)

Maybe Cocoa is a bit different but in Cocoa Touch you have subviews overlapping each other all the time I can't imaging how it would be if draw order is undefined.

--

Johannes Lundberg

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

BRILLIANTSERVICE CO., LTD.

My blog

Mirama homepage blog

Company homepage

On Wed, Oct 2, 2013 at 11:28 PM, Matt Rice <ratmice@gmail.com> wrote:

On Wed, Oct 2, 2013 at 6:47 AM, Fred Kiefer <fredkiefer@gmx.de> wrote:
> I think this is an unrelated issue.

probably, just wanted to throw it out there as one possible avenue, as
I recall this one being not so fun to figure out.

> First off, I always thought the drawing order of sibling views is undefined. Could you please point me to a document that states otherwise?

I know of no such document, it is undefined.

> Still if Apple followes the order in wich views wher added, we should do so two. But as far as I remember this is already the case.
> And overlapping sibling views are a no-go in GNUstep, they might work for drawing, but event handling will be screwed up.

Correct, on OPENSTEP/the osx's i've tested this was the case,
drawing was done in the order added (so back-most in the sibling views
array was on top) IIRC

event handling was done in the opposite order (so the back-most
top-displayed view had first shot at the event)

when using views that overlap it required care from the developer that
all sibling NSViews which overlap the rectangle needing display
-setNeedsDisplay at the same time, if you setNeedsDisplay a view which
is not top-most (while not setNeedsDisplay on the top-most),
display will become out of sync with event handling, thus it was
something which worked with the correct parameters, was technically
undefined, because its possible to get bad results.

similarly, if the top-most view doesn't respond to events, and the a
view it overlaps does respond to events you are likely screwed as
well.

its not something they want to define/advertise because honestly there
are more ways to screw it up than do it correctly.  but it has worked
given a careful implementation.

> Could you please provide an example that demonstrates the issue? After the weekend I am Wiiling to look into this.

I don't really have a test case for it or a gnustep install around,
afaik until now DBModeler was the only thing using this feature and I
haven't compiled it in years, and it is undoubtedly broken.

hopefully Johannes can come up with something that exhibits the problem.