Maybe people could resign their useless “We want iOS” points to this feedback report from March 2013?
25108 - Xojo application is not retina display aware.
Feedback Case #25108
With the affordability and subsequent proliferation of Retina and 4k and 5k screens this would be useful as Xojo simply looks awful on them.
[and before someone asks: “useless” because iOS is coming soon, so there is no point asking for it]
Done.
Still have 2 not used.
I think we need 3 independent cases:
I know that developers need to do their homework like make picture 2 times the size, but the framework and the IDE should support it.
22nd let’s get it into the top 10!
After all, first impressions count, and if Xojo and Xojo apps look ugly as hell then new developers/users will not give Xojo/your app a second look
Actually here is the link
(https://xojo.com/issue/25108)]Xojo application is not retina display aware
Markus, you left out the : in the URL
Looking good is completely different than being usable in a high-density pixel environment. When it comes to resizing and moving things around, my main program takes a pretty big performance hit when going from non-Retina to Retina (also Carbon to Cocoa). It is still usable but no where near as snappy. But also, the UI in my main program is nowhere near as complicated as the Xojo IDE. Maybe they can do it already, but the performance is not acceptable?
I would not expect retina support until the new framework is brought to desktop. Then the IDE won’t support it until the IDE is ported to the new framework. Despite a number of engineers using retina screens, including Geoff, it was a low priority when I was there and I don’t see any indication that has changed.
Feedback priorities are a strong signal to us. I’ll leave it at that.
I thought about this the other night…
I think there is a sorta cheapish hack that could be done in Xojo to make it easier to get a Retina solution.
Xojo Pictures have a vertical and horizontal resolution, If Xojo were to modify their picture -> NSImage code to automatically set the size of the NSImage to picture size / horizontal (or vertical) resolution it would solve some of the issues. All that’s left is the Bevel Button and Listbox (AFAIK) which again could take advantage of the meta data to draw the image at a reduced size.
It might not be pretty as it not really using different representations, and it would kill sales of my Retina Kit, but at the end of the day it would enable a Retina solution much earlier.
Note: I don’t actually know what goes on under the hood, I can only speculate, based upon my own experience with the Retina Kit, it may not be technically feasible.
When you consider that Retina graphics are 4x the pixels, it makes sense. You really have to optimize your drawing routines as much as possible.
CGLayers can help a lot, but are a pain to use with native Xojo drawing code, they also have a initial performance hit when creating them.
For instance in our latest project, using Xojo draw picture was taking 12,000 ms to update the entire canvas (in the paint event). Once everything had been converted over to CGLayers (it’s an icon grid so I could use a CGLayer per icon), it was down to 3,000 ms, on a Retina display. Where I could, I also used invalidate and passed in a rect to update just the area needed, it reduced drawing down to 398 ms. On a 27" Thunderbolt display, the paint code was reduced to 1,900 ms, and updating just one area was as quick 198 ms.
Otherwise, there’s a bunch of tricks you can do to gain performance.
#1 Store a cached version of your image no bigger than 2x the size you intend to draw it, the less resizing the better.
#2 When you need to update fast, use CGContext declares to reduce the image interpolation and disable anti-Alias. i.e. as the user moves objects around inside the canvas.
#3 Always disable font smoothing, most of the time fonts look better with it off and you’ll gain a wee bit of speed.
#4 Cache as much as possible. Avoid calculating image locations, doing any unnecessary math in the paint even. You want the code in the paint event to simply paint, save the math for a update layout event.
#5 Use invalidate( left, top, width, height ) on just the areas that need re-painting.
[quote=149192:@Sam Rowlands]#4 Cache as much as possible. Avoid calculating image locations, doing any unnecessary math in the paint even. You want the code in the paint event to simply paint, save the math for a update layout event.
#5 Use invalidate( left, top, width, height ) on just the areas that need re-painting.[/quote]
These are by far the most important optimizations when working with a Canvas. I’d only go looking into declares and image caching if profiling led me to believe that wasn’t enough for the job at hand.
The icon grid is in a scrollview, so when the view was scrolled the entire visible page was refreshed (I used needsToDraw to check each rect to see if it needs to be drawn). Our icons are 256 on the longest side, which means that each icon had to have a graphic of 512 on the longest side. drawPicture and CGContextDrawImage (which is what I’m guessing Xojo uses underneath) just were not smooth enough IMHO.
doesn’t the Xojo picture class already have a CGImage cached for the picture?
And doesn’t NSImage on Cocoa already have cached resized versions of an image for faster drawing?