Canvas and FocusRing - slow performance

Hi,

The drawing performance slows down while having a focus ring around a canvas. I know there is a feedback case open since 2013 but
it haven’t solved yet. The focus ring has a great impact in the performance especially when you want soft scrolling ector senstive operations do to.
fps drop about 50% more or less It’s not really nice with that bug. Any advices ?

[quote=202492:@Rob Egal]Hi,

The drawing performance slows down while having a focus ring around a canvas. I know there is a feedback case open since 2013 but
it haven’t solved yet. The focus ring has a great impact in the performance especially when you want soft scrolling ector senstive operations do to.
fps drop about 50% more or less It’s not really nice with that bug. Any advices ?[/quote]

I see three things to try :

1 - Rest the canvas on top of another, which will be the one showing the focus ring. In terms of appearance, it will be just exactly the same. I suspect the slow down is related to the painting of the control, and you don’t care about the one underneath.

2 - Draw the focus ring inside the canvas. It will take two pixels on each side.

3 - Rest the canvas on top and in the center of a rectangle four pixels wider and higher, that has a border color slightly lighter than the background color, just the same as the two pixels of the focus ring. Make sure the canvas is not child, and use the rectangle Visible property to show the focus ring when needed.

1 and 3 do not draw any resource from the canvas itself, so they should not slow down the control. 2 Requires drawing two extra rectangles, which takes a bit of time, and can be a problem in very fast display. It also takes away a couple pixels on each side. But you can compensate and make the canvas wider and higher upon switching on the ring.

On Windows, I would refrain from stacking controls, and use 2 to minimize flicker.

Thats a very old issue.
feedback://showreport?report_id=26903

Unfortunately an old issue - true.

I’ve solved it by clearing the focus for drawing intense operation and reactivating it afterwards.
It’s not nice but the best I can do. This kind of bugs/issues and is really annoying + extra time for finding workarounds.

It’s seems the slow down comes for the focus drawing underneath - yes.

[quote=203424:@Rob Egal]Unfortunately an old issue - true.

I’ve solved it by clearing the focus for drawing intense operation and reactivating it afterwards.
It’s not nice but the best I can do. This kind of bugs/issues and is really annoying + extra time for finding workarounds.

It’s seems the slow down comes for the focus drawing underneath - yes.[/quote]

I suspect the issue is not Xojo, but Cocoa related.

I do think so too. Apple talks about possible slowdowns in its View programming guide, and one option would be to override the opaque property and return True if your canvas is not (at least partly) transparent.

If that is what happens, could you come up with a declare to set these properties ? Although I do not quite see how one would return True in Paint…

I remember this rather long thread https://forum.xojo.com/14202-drag-border-vs-focusring-visual-cues-and-drop-file-selected/4 where we battled the framework to get the focus ring while dragging anything that was not a picture file.

The Cocoa focus ring is not a kitten.

In the end, I have been using the blue rectangle workaround ever since and never had to contend with a finicky blue aura again…

The bad thing is, in that case you have to subclass the canvas – and this would mean the XojCanvas – to install a “isOpaque” method on its Cocoa side and create and attach possible Xojo controllers or delegates too. While I could imagine that on a custom NSView control, I don’t think subclassing a Xojo control on OS X level is such a good idea – its implementation could change when it’s adapted to new OS features, and most of all I don’t want to read what Norman would tell me if I break anything :wink:

I’d rather go with a workaround first and try it later when r3 is out – like written I ported a lot of iOSLib to a similar OS X lib and could try it on it.

In theory, the implementation would tweak the OS X isOpaque call to a Xojo method that possibly reads the instance’s Opaque value from a class dictionary (far as I know the best way to exchange custom control values between Xojo and System side) and return this boolean.

The canvas has a transparent property and a erase background property, I always unselect these unless I need transparency.

You could try using layer backed views.