Re: Erasing drawn content
Thanks everyone for all the great suggestions. I'll try it out and report back how it went. The clipping path method seems promising. Except that would still rely on inserting a custom view in the WebView's private scrollview hierarchy. It doesn't really. Inserting a NSBee as a subview of the WebView would produce the same results as creating an overlay Window. To justify a bit why I decided to just insert it in the WebView. If you draw an overlay on top (what I was doing at first), you still need to access the WebView's scrollview in order to observe its contentView's frame (so your overlay can match the content size and exclude any scrollbars from the overlay) and its documentView's bounds (so you can account for the scrolling and reposition your drawing). Drawing an overlay does in fact tend to save you some memory, but on the other hand requires a lot of redrawing when you resize or scroll your WebView. Since both methods basically rely on the WebView's main scroll view being where it is, I don't think that inserting a view is much more dangerous than doing an overlay on top. And for those who just tuned in, NSBee is of course a NSView. smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Oops, wrong email address, I try again: Pity, I like the idea of more bee-based metaphors in APIs (or Apis). It could be known as Bee-OS. That was a pun in latin? Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On 9 Jun 2010, at 10:02, vincent habchi wrote: Oops, wrong email address, I try again: Pity, I like the idea of more bee-based metaphors in APIs (or Apis). It could be known as Bee-OS. That was a pun in latin? http://en.wikipedia.org/wiki/BeOS (which was once a candidate for the base of Mac OS X) Kind regards, Alastair. -- http://alastairs-place.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Le 9 juin 2010 à 13:33, Alastair Houghton a écrit : On 9 Jun 2010, at 10:02, vincent habchi wrote: Pity, I like the idea of more bee-based metaphors in APIs (or Apis). It could be known as Bee-OS. That was a pun in latin? http://en.wikipedia.org/wiki/BeOS (which was once a candidate for the base of Mac OS X) Yes, I know of Be-OS, and I have a NeXTStation somewhere a heap of old computers (an Oric 1, too, and various Atari ST/TT/Falcon). But the point was that apis, in latin, means bee. Cheers Vincent___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On 09/06/2010, at 9:38 PM, vincent habchi wrote: But the point was that apis, in latin, means bee. I think we ought to buzz off and hive this off-list, or else we're likely to get smoked out by the moderator. (Beesides, any joke that needs explaining loses any small element of humour it might have had). --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On 9 Jun 2010, at 12:38, vincent habchi wrote: Le 9 juin 2010 à 13:33, Alastair Houghton a écrit : On 9 Jun 2010, at 10:02, vincent habchi wrote: Pity, I like the idea of more bee-based metaphors in APIs (or Apis). It could be known as Bee-OS. That was a pun in latin? http://en.wikipedia.org/wiki/BeOS (which was once a candidate for the base of Mac OS X) Yes, I know of Be-OS, and I have a NeXTStation somewhere a heap of old computers (an Oric 1, too, and various Atari ST/TT/Falcon). But the point was that apis, in latin, means bee. Oh, sorry, I see :-) :-) I hadn't spotted that. Kind regards, Alastair. -- http://alastairs-place.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Le 9 juin 2010 à 13:44, Graham Cox a écrit : On 09/06/2010, at 9:38 PM, vincent habchi wrote: But the point was that apis, in latin, means bee. I think we ought to buzz off and hive this off-list, or else we're likely to get smoked out by the moderator. (Beesides, any joke that needs explaining loses any small element of humour it might have had). You're right. Let's say it was the five minutes Cocoa-U thread. :) Vale atque salve ! :) Vincent (going to lunch anyhow)___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Except that would still rely on inserting a custom view in the WebView's private scrollview hierarchy. If the clipping path method works, and if you can subclass your webview, then you shouldn't need a separate view at all. Just override drawRect: and draw your rectangles after calling super. It sounds almost too easy. Regards, Paul Sanders. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On Jun 9, 2010, at 10:07 AM, Paul Sanders wrote: If the clipping path method works, and if you can subclass your webview, then you shouldn't need a separate view at all. Just override drawRect: and draw your rectangles after calling super. It sounds almost too easy. Actually there are subviews inside a WebView, one per frame; it’s those you’d need to subclass and I don’t think there’s a public factory method you can override, so I don’t know how you’d get your subclass instantiated. Also, while overriding -drawRect: works for many views, I have serious doubts it would work for WebKit content. WebKit rendering is insanely complex and I’m pretty sure it’s not all bottlenecked through the -drawRect: call. That is, I think in many situations it will just lockFocus and draw into its view directly instead of calling -setNeedsDisplayInRect: and waiting for AppKit to redraw it. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
The clipping path approach doesn't really help. It turns out that you can only intersect the current clipping path (initially the view's bounds) with a new path and the intersected region is the region where drawing is visible. This means that when you're drawing a larger rectangle over a smaller one, you would need to set the clipping path to all areas NOT covered by the smaller rectangle. This is basically the same problem as calculating which parts of the larger rectangle to draw and just drawing there. The layer approach din't work out as well. I get the same black color problem as with the view. Overriding drawRect: is problematic for WebViews, as Jens pointed out WebViews do all sorts of drawing voodoo. Believe me, I've tried. It seems that the only option left manually doing difference operations (or doing an overlay window) on the rectangles and drawing only the uncovered portions. Set operations on NSBezierPath would definitely help. I found a nice category on cocoadev (http://www.cocoadev.com/index.pl?NSBezierPathcombinatorics) but it uses the General Polygon Clipper (which I won't be able to use due to licensing issues). Does perhaps anyone else know of a convenient method (library) to do difference operations on rectangular shapes (i.e., draw a NSRect but not the points that are in an array of other NSRects)? If the clipping path method works, and if you can subclass your webview, then you shouldn't need a separate view at all. Just override drawRect: and draw your rectangles after calling super. It sounds almost too easy. smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On Jun 9, 2010, at 11:06, Matej Bukovinski wrote: The clipping path approach doesn't really help. It turns out that you can only intersect the current clipping path (initially the view's bounds) with a new path and the intersected region is the region where drawing is visible. This means that when you're drawing a larger rectangle over a smaller one, you would need to set the clipping path to all areas NOT covered by the smaller rectangle. This is basically the same problem as calculating which parts of the larger rectangle to draw and just drawing there. I think you can do it, but it just takes an extra step. For each overlay (front to back): 1. Intersect the rect for the current overlay with the drawRect (i.e. the rect passed to drawRect:) producing the effective tintRect. 1a. If tintRect is empty, nothing to draw, so skip 2-4. 2. Fill the tint rect with the appropriate color. 3. Construct a new bezier compound-path object with one path from drawRect (+[NSBezierPath bezierPathWithRect:]), plus a path from the tintRect (-[NSBezierPath appendBezierPathWithRect:]). That essentially inverts the tintRect within drawRect. Set the even-odd winding rule on the path, so that you don't have to be concerned about subpath directions (although I believe creating a compound path in the order I described will give correct results with non-zero winding rule, too). 4. Intersect this compound path with the current clipping path (-[NSBezierPath addClip]). Repeat for each overlay rect. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On 9 Jun 2010, at 19:06, Matej Bukovinski wrote: The layer approach din't work out as well. I get the same black color problem as with the view. Overriding drawRect: is problematic for WebViews, as Jens pointed out WebViews do all sorts of drawing voodoo. Believe me, I've tried. It seems that the only option left manually doing difference operations (or doing an overlay window) on the rectangles and drawing only the uncovered portions. Set operations on NSBezierPath would definitely help. If it were *my* program, I think I'd just use an overlay window; that way you can draw what you please and you don't have to worry about what WebKit (or some plug-in) may or may not be doing. FWIW, rectangle intersections are pretty easy (just draw the cases on a piece of paper and you'll see what I mean). General Boolean ops are a *much* harder problem, but you *really* don't need that for what you're doing. Kind regards, Alastair. -- http://alastairs-place.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
I might as well take a stab at this: - Draw into an NSImage, filling the shapes as fully opaque. - Composite/draw the image into your view with whatever alpha you need via the fraction argument. - Draw the outlines, which I assume you want to be fully opaque, directly into the view. Haven't tried it myself but I think it should work. paul ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On 9 Jun 2010, at 20:15, Paul Kim wrote: I might as well take a stab at this: - Draw into an NSImage, filling the shapes as fully opaque. A transparency layer would be better. However, this doesn't really deal with the underlying problem that WebKit rendering is hairy and so you're taking a risk just using an overlaid view. Better to use a window IMO. Kind regards, Alastair. -- http://alastairs-place.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Yep that didi it. Thanks for proving me wrong Quincey.
Here's a working solution:
// Overlay View
- (void)drawRect:(NSRect)drawRect {
[NSGraphicsContext saveGraphicsState];
// Draw all anotations, make sure _annotations is sorted front-to-back
for (Annotation *a in _annotations) {
[a draw:drawRect];
}
[NSGraphicsContext restoreGraphicsState];
}
// Annotation
- (void)draw:(NSRect)drawRect {
NSRect nodeRect = [_node boundingBox];
if (!NSIntersectsRect(nodeRect, drawRect)) {
return; // nothing to draw
}
// Fill the background
[[self annotationFillColor] set];
[NSBezierPath fillRect:nodeRect];
// Stroke the border
[[self annotationStrokeColor] set];
[NSBezierPath setDefaultLineWidth:2.0];
[NSBezierPath strokeRect:nodeRect];
// Draw the title
[[self labelAttributedString] drawAtPoint:[self
annotationLabelPositionFor:nodeRect]];
// Clip
NSBezierPath* clipPath = [NSBezierPath bezierPathWithRect:drawRect];
[clipPath appendBezierPathWithRect:nodeRect];
[clipPath setWindingRule:NSEvenOddWindingRule];
[clipPath addClip];
}
On Jun 9, 2010, at 11:06, Matej Bukovinski wrote:
The clipping path approach doesn't really help. It turns out that you can
only intersect the current clipping path (initially the view's bounds) with
a new path and the intersected region is the region where drawing is
visible. This means that when you're drawing a larger rectangle over a
smaller one, you would need to set the clipping path to all areas NOT
covered by the smaller rectangle. This is basically the same problem as
calculating which parts of the larger rectangle to draw and just drawing
there.
I think you can do it, but it just takes an extra step. For each overlay
(front to back):
1. Intersect the rect for the current overlay with the drawRect (i.e. the
rect passed to drawRect:) producing the effective tintRect.
1a. If tintRect is empty, nothing to draw, so skip 2-4.
2. Fill the tint rect with the appropriate color.
3. Construct a new bezier compound-path object with one path from drawRect
(+[NSBezierPath bezierPathWithRect:]), plus a path from the tintRect
(-[NSBezierPath appendBezierPathWithRect:]). That essentially inverts the
tintRect within drawRect. Set the even-odd winding rule on the path, so that
you don't have to be concerned about subpath directions (although I believe
creating a compound path in the order I described will give correct results
with non-zero winding rule, too).
4. Intersect this compound path with the current clipping path
(-[NSBezierPath addClip]).
Repeat for each overlay rect.
smime.p7s
Description: S/MIME cryptographic signature
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On Jun 9, 2010, at 13:00, Matej Bukovinski wrote:
// Overlay View
- (void)drawRect:(NSRect)drawRect {
[NSGraphicsContext saveGraphicsState];
// Draw all anotations, make sure _annotations is sorted front-to-back
for (Annotation *a in _annotations) {
[a draw:drawRect];
}
[NSGraphicsContext restoreGraphicsState];
}
// Annotation
- (void)draw:(NSRect)drawRect {
NSRect nodeRect = [_node boundingBox];
if (!NSIntersectsRect(nodeRect, drawRect)) {
return; // nothing to draw
}
// Fill the background
[[self annotationFillColor] set];
[NSBezierPath fillRect:nodeRect];
// Stroke the border
[[self annotationStrokeColor] set];
[NSBezierPath setDefaultLineWidth:2.0];
[NSBezierPath strokeRect:nodeRect];
// Draw the title
[[self labelAttributedString] drawAtPoint:[self
annotationLabelPositionFor:nodeRect]];
// Clip
NSBezierPath* clipPath = [NSBezierPath bezierPathWithRect:drawRect];
[clipPath appendBezierPathWithRect:nodeRect];
[clipPath setWindingRule:NSEvenOddWindingRule];
[clipPath addClip];
}
I see a couple of minor issues with this:
1. I don't think it's necessary or desirable to save/restore the graphics state
around the drawRect: behavior, because I believe that's done for you around the
drawRect: invocation itself. You'd only need it if you had other non-clipped
drawing to do after drawing your annotations.
2. Instead of this:
[clipPath appendBezierPathWithRect:nodeRect];
I actually meant this:
[clipPath appendBezierPathWithRect: NSIntersectionRect (drawRect,
nodeRect)];
Otherwise the compound shape isn't what you want it to be. However, the two
versions are probably equivalent in this context, because everything's clipped
to drawRect anyway.
3. Since your 2.0-point strokes are drawn centered on the nodeRect path, only
the interior half of the strokes get protected by the clipping changes. The
effect may or may not be what you want, and may or may not be visible,
depending on the alpha values of the various colors involved.
One solution is to draw the strokes *inside* the nodeRect (by creating an inset
bezier path specifically for stroking, for example). Or, expand your clipping
protection to include the stroke:
[clipPath appendBezierPathWithRect: NSIntersectionRect (drawRect,
NSInsetRect (nodeRect, -1.0, -1.0))]; // 1.0 == strokeWidth / 2
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Erasing drawn content
I see a couple of minor issues with this: 1. I don't think it's necessary or desirable to save/restore the graphics state around the drawRect: behavior, because I believe that's done for you around the drawRect: invocation itself. You'd only need it if you had other non-clipped drawing to do after drawing your annotations. That's correct. I have some additional (debug) drawing code after (that I din't include in the posting) and needed to restore the full clipping path for this. I should have probably deleted the NSGraphicsContext calls when posting the code here. 2. Instead of this: [clipPath appendBezierPathWithRect:nodeRect]; I actually meant this: [clipPath appendBezierPathWithRect: NSIntersectionRect (drawRect, nodeRect)]; Otherwise the compound shape isn't what you want it to be. However, the two versions are probably equivalent in this context, because everything's clipped to drawRect anyway. I see why this makes sense, but I don't think it's necessary, since anything that would have been outside the drawRect would be removed when doing the addClip call (since we make an intersection with an existing clipping path that is at most drawRect size). It doesn't hurt though if it's included, it might even make things easier for NSBezierPath. 3. Since your 2.0-point strokes are drawn centered on the nodeRect path, only the interior half of the strokes get protected by the clipping changes. The effect may or may not be what you want, and may or may not be visible, depending on the alpha values of the various colors involved. One solution is to draw the strokes *inside* the nodeRect (by creating an inset bezier path specifically for stroking, for example). Or, expand your clipping protection to include the stroke: [clipPath appendBezierPathWithRect: NSIntersectionRect (drawRect, NSInsetRect (nodeRect, -1.0, -1.0))]; // 1.0 == strokeWidth / 2 Thanks for pointing this out. I would have noticed this sooner or later. At least I hope so. :) smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Erasing drawn content
Hi, In a cocoa application that I'm developing I have a custom NSView subclass that I use as an overlay view for annotating a WebView. The overlay view draws semi-trasparent rectangles in its drawRect: method for DOM elements that were selected by the user. Since the fill color for the drawn rectangles is semi-transparent, the pixel values get added up when a smaller rectangle is drawn over a larger one (here's an example http://cl.ly/4fecb8fac0abff6ef6ac , as you can see the smaller rectangle has a darker background because of the larger rectangle, that was drawn first). This is especially problematic if the rectangles are of different colors, since color mixing occurs. I would like to prevent this sort of behavior by somehow erasing the content that was perviously drawn (i.e., making the background transparent again) before drawing with a new element. Does anyone have an idea how to achieve this? Thank you for your time. Best regards, Matej smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Perhaps call NSRectFillUsingOperation(rect, NSCompositeClear) before drawing each rectangle? On Jun 8, 2010, at 5:32 AM, Matej Bukovinski wrote: * PGP Bad Signature, Signed by an unverified key Hi, In a cocoa application that I'm developing I have a custom NSView subclass that I use as an overlay view for annotating a WebView. The overlay view draws semi-trasparent rectangles in its drawRect: method for DOM elements that were selected by the user. Since the fill color for the drawn rectangles is semi-transparent, the pixel values get added up when a smaller rectangle is drawn over a larger one (here's an example http://cl.ly/4fecb8fac0abff6ef6ac , as you can see the smaller rectangle has a darker background because of the larger rectangle, that was drawn first). This is especially problematic if the rectangles are of different colors, since color mixing occurs. I would like to prevent this sort of behavior by somehow erasing the content that was perviously drawn (i.e., making the background transparent again) before drawing with a new element. Does anyone have an idea how to achieve this? Thank you for your time. Best regards, Matej * Matej Bukovinski ma...@bukovinski.com * Issuer: The USERTRUST Network - Unverified ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Thanks for the suggestion Steve. Unfortunately this causes the background to turn black and not transparent. I would need the view to become transparent (so the WebView underneath is visible). On 8.6.2010, at 16:04, Steve Christensen wrote: Perhaps call NSRectFillUsingOperation(rect, NSCompositeClear) before drawing each rectangle? On Jun 8, 2010, at 5:32 AM, Matej Bukovinski wrote: * PGP Bad Signature, Signed by an unverified key Hi, In a cocoa application that I'm developing I have a custom NSView subclass that I use as an overlay view for annotating a WebView. The overlay view draws semi-trasparent rectangles in its drawRect: method for DOM elements that were selected by the user. Since the fill color for the drawn rectangles is semi-transparent, the pixel values get added up when a smaller rectangle is drawn over a larger one (here's an example http://cl.ly/4fecb8fac0abff6ef6ac , as you can see the smaller rectangle has a darker background because of the larger rectangle, that was drawn first). This is especially problematic if the rectangles are of different colors, since color mixing occurs. I would like to prevent this sort of behavior by somehow erasing the content that was perviously drawn (i.e., making the background transparent again) before drawing with a new element. Does anyone have an idea how to achieve this? Thank you for your time. Best regards, Matej * Matej Bukovinski ma...@bukovinski.com * Issuer: The USERTRUST Network - Unverified smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Unfortunately this causes the background to turn black and not transparent. I would need the view to become transparent (so the WebView underneath is visible). Try this: [[NSColor clearColor] setFill]; NSRectFill (myRect); That's what I do. Regards, Paul Sanders ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On Jun 8, 2010, at 8:41 AM, Matej Bukovinski ma...@bukovinski.com wrote: Thanks for the suggestion Steve. Unfortunately this causes the background to turn black and not transparent. I would need the view to become transparent (so the WebView underneath is visible). You can't do this. All your bees are composited back-to-front into the window's backing store, so filling with anything will obliterate your web view's drawing. What you need to do is draw the correct stuff in -drawRect:, and invalidate the proper regions using -setNeedsDisplayInRect: in response to changes in your web view. --Kyle Sluder (Sent from the line for Pacific Heights at WWDC) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On Jun 8, 2010, at 10:03 AM, Kyle Sluder kyle.slu...@gmail.com wrote: You can't do this. All your bees are composited back-to-front into the window's backing store, so filling with anything will obliterate your web view's drawing. Of course by bees, I meant views. --Kyle Sluder (Still on line for Pacific Heights at WWDC) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Sadly this also turns the background black just like a NSCompositeClear fill operation. On 8.6.2010, at 17:56, Paul Sanders wrote: Unfortunately this causes the background to turn black and not transparent. I would need the view to become transparent (so the WebView underneath is visible). Try this: [[NSColor clearColor] setFill]; NSRectFill (myRect); That's what I do. Regards, Paul Sanders smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Thanks Kyle. Drawing only the portions that won't be covered by a smaller rectangle is the obvious solution to this problem but unfortunately one that requires a lot of drawing logic (especially when you can have several nested rectangles). I was hoping there exists a more elegant way of achieving this. It would have saved me a lot of math. Have a great time at the WWDC. What you need to do is draw the correct stuff in -drawRect:, and invalidate the proper regions using -setNeedsDisplayInRect: in response to changes in your web view. smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On Jun 8, 2010, at 10:03 AM, Kyle Sluder kyle.slu...@gmail.com wrote: You can't do this. All your views are composited back-to-front into the window's backing store, so filling with anything will obliterate your web view's drawing. Of course, silly me. Can something be done with a layer-backed view here, used as some kind of overlay? Alternatively, one could position a borderless window over the WebView and draw your rectangles into that. This window can be made initially transparent by: - calling setOpaque: NO on the window - having the content view return isOpaque as YES - filling the content view with clearColor Then draw your rectangles in the content view of this window and the NSRectFill trick should work. Regards, Paul Sanders. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
Could you perhaps elaborate a bit how you think that a layer backed view could help? The window overlay sounds like it could work. Hoverer, a NSView overlay would be preferred since I'm inserting the overlay in the WebView's scroll view (and matching the documents view size via bounds change notifications). This works very well when scrolling both the web and overlay view at the same time (and is also efficient). Of course, silly me. Can something be done with a layer-backed view here, used as some kind of overlay? Alternatively, one could position a borderless window over the WebView and draw your rectangles into that. This window can be made initially transparent by: - calling setOpaque: NO on the window - having the content view return isOpaque as YES - filling the content view with clearColor Then draw your rectangles in the content view of this window and the NSRectFill trick should work. smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On Jun 8, 2010, at 2:02 PM, Matej Bukovinski ma...@bukovinski.com wrote: Could you perhaps elaborate a bit how you think that a layer backed view could help? Layers are composed into their own backing stores, so you can accumulate data there rather than recalculating it every time you need to repaint. That said, you would need to use a layer hosting view rather than a layer backed view, which might put you at a disadvantage from where you started. The window overlay sounds like it could work. Hoverer, a NSView overlay would be preferred since I'm inserting the overlay in the WebView's scroll view (and matching the documents view size via bounds change notifications). This works very well when scrolling both the web and overlay view at the same time (and is also efficient). I don't believe you're actually allowed to mess with the web view's scroll view hierarchy; the web view comes with a prepackaged scroll view, unlike say NSTextView. It sounds like the overlay window is the best bet. --Kyle Sluder (Sent from WWDC)___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
The window overlay sounds like it could work. Hoverer, a NSView overlay would be preferred since I'm inserting the overlay in the WebView's scroll view (and matching the documents view size via bounds change notifications). This works very well when scrolling both the web and overlay view at the same time (and is also efficient). A layer-backed (or layer-hosted) view matching the bounds of a large web page would use a lot of memory (bounds.width * bounds.height * 4 bytes, probably). I would handle scrolling in the overlay window yourself by offsetting the content view's bounds in the way that a scrollview does for its document view. Flipping the view's coordinates might help with the maths. It looks like listening for NSViewBoundsDidChangeNotification will let you track the scroll position of the webview and you need only draw those rectanges which are visible, of course. Kyle, I rather liked your stack of 'bees'. Regards, Paul Sanders. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
The window overlay sounds like it could work. Hoverer, a NSView overlay would be preferred since I'm inserting the overlay in the WebView's scroll view (and matching the documents view size via bounds change notifications). This works very well when scrolling both the web and overlay view at the same time (and is also efficient). Also, you can probably make your overlay window a child window of the window containing the webview. Then: - it will stay on top of it - it will move with it Regards, Paul Sanders. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On Jun 8, 2010, at 14:10, Kyle Sluder wrote: It sounds like the overlay window is the best bet. Surely it's easier to do what the OP wanted with a clipping path? In drawRect: just draw the tint rectangles front-to-back instead of back-to-front, and after drawing each one remove the rect's interior from the clipping path. No off-screen drawing is needed, nor any complex logic to draw all the non-overlapping rectangle pieces separately. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On Tue, Jun 8, 2010 at 4:05 PM, Quincey Morris quinceymor...@earthlink.net wrote: On Jun 8, 2010, at 14:10, Kyle Sluder wrote: Surely it's easier to do what the OP wanted with a clipping path? In drawRect: just draw the tint rectangles front-to-back instead of back-to-front, and after drawing each one remove the rect's interior from the clipping path. No off-screen drawing is needed, nor any complex logic to draw all the non-overlapping rectangle pieces separately. Except that would still rely on inserting a custom view in the WebView's private scrollview hierarchy. --Kyle Sluder (Waiting for an Apple Engineer in the Cocoa Lab at WWDC) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On 09/06/2010, at 3:06 AM, Kyle Sluder wrote: Of course by bees, I meant views. Pity, I like the idea of more bee-based metaphors in APIs (or Apis). It could be known as Bee-OS. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Erasing drawn content
On Jun 8, 2010, at 8:58 PM, Graham Cox wrote: On 09/06/2010, at 3:06 AM, Kyle Sluder wrote: Of course by bees, I meant views. Pity, I like the idea of more bee-based metaphors in APIs (or Apis). It could be known as Bee-OS. Nice double pun! --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
