In an engineering meeting, I mentioned a discussion I had with a user about the speed of the Layout Editor and Travis said he had recently been reminded of how slow it was too. While most of the time issues in Xojo are carefully calculated and prioritized for maximum bang for the buck (as we say around here), that’s not always how it happens. After the meeting, Travis decided to dive into the Layout Editor code and see what could be done to speed it up.

The results are pretty remarkable.

The video below tells the story best.

The difference is greatest for layouts with a lot of controls.

To optimize for speed, we made two changes:

1. On all platforms, selecting and dragging controls now only re-renders those controls that are selected. A buffered image (picture) is taken with everything but the selected controls, and thus only the selected controls have to be drawn on top of that as they move. This is an improvement from before, where every control was re-rendered in every frame whether it was moving or not.
2. The second optimization is Mac-specific. Some controls take a long time for macOS to draw and composite. In particular, controls like Group Boxes in Dark Mode can take a while. We now keep a cached copy of the rendered control from the operating system, and use that unless its size or properties change. That way, we don’t need to wait for macOS to draw the control every time we want to display or move it on the screen.

If you have layouts with lots of controls, check out 2019r1. You’re in for a pleasant surprise.

In 2016 we took many big steps forward with Xojo including HiDPI support for macOS (Retina), Windows and the web, hardware-acellerated graphics for Windows, tons of new iOS features, IDE improvements and compiler optimization for 64-bit builds. Check out the 2016 Release Highlights. The Xojo Forum has grown to over 16,000 members. We published our 100th video in the Xojo YouTube Channel and added new playlists for Raspberry Pi and Web Services and more new videos in our Spanish, Italian and German language playlists.

We hosted another highly successful Xojo Developer Conference in Houston, Texas and we’ll have an announcement soon about the next XDC. 2016 was another great year for Xojo and 2017 is looking even better! One of my favorite things is hearing about all the cool projects our users create and I have no doubt that there will be many more this year.

From everyone here at Xojo, Happy New Year!

General Changes

First, the Web Framework now has support for Retina/HiDPI in supported browsers. All controls have been updated with new graphics to allow your Web Apps to look great on any screen. All you have to do is just flip the “Supports Retina/HiDPI” switch and start using Image objects instead of Pictures and you’re off and running!

NOTE: Regardless of whether you check the “Supports Retina/HiDPI” switch, the web framework now stores all of your image assets in the Resources directory next to your app and they are only loaded momentarily when a browser requests one. This means that your app should use a lot less memory overall.

Controls

WebCanvas: HiDPI/Retina drawing out of the box! No code change required!

WebPicture: Just start using Images instead of Pictures and flip the Retina/HiDPI switch and the web framework will automatically send the correct resolution image to the browser.

WebImageView: Because it’s backed with a WebPicture, it just works!

WebToolbar: Toolbar icons now support Images as well.

Events

WebSession.ScaleFactorChanged: Fires whenever the ScaleFactor of the current session’s browser changes.

Properties

WebSession.ScaleFactor (Read-Only): Reflects the current ScaleFactor of the browser.

WebSDK

The WebSDK has been given a ScaleFactorChanged event so your control is notified when a change occurs instead of your control needing to periodically check the ScaleFactor property on the Session object.

WebControlWrapper.ScaleFactorChanged: Fires whenever the ScaleFactor of the current session’s browser changes.

Also for WebSDK, we are now enforcing unique Javascript Namespaces throughout a project at compile time. This means you’ll be able to tell ahead of time if your controls are missing a namespace or if you’ve inadvertently used the same exact namespace more than once!

*As with other posts, we’ll use “HiDPI” to refer to both HiDPI on Windows and Retina on OS X.

If drawing directly into the Graphics object passed into the control’€™s Paint event isn’€™t feasible or you need to manage your own caching of costly drawing for some reason, the BitmapForCaching function can be used to create a mutable bitmap that’s configured appropriately for using as a cache. This bitmap has some screen-specific properties, like the scale factor, and should be thrown away in the ScaleFactorChanged event. For example:

Class Foo

 Inherits Canvas

 Sub Paint(g As Graphics) Handles Event

  CreateCacheIfNeeded()

  g.DrawPicture(mCachedContent, 0, 0)

 End Sub
 Sub ScaleFactorChanged() Handles Event

  mCachedContent = Nil

 End Sub
 Private Sub CreateCacheIfNeeded()

  If mCachedContent <> Nil Then Exit Sub
  // Pretend this is a costly operation

  mCachedContent = Self.TrueWindow.BitmapForCaching(100, 100)

  Dim g As Graphics = mCachedContent.Graphics

  g.FillRect(0, 0, g.Width, g.Height)

 End Sub
 Private Dim mCachedContent As Picture

End Class
]]>
					
					https://blog.xojo.com/2016/04/07/advanced-retinahidpi-bitmapforcaching-and-scalefactorchanged/feed/
			2
		
		
			
		
		
		https://blog.xojo.com/2016/04/05/xojo-retinahidpi-the-journey-of-a-thousand-pixels/
					https://blog.xojo.com/2016/04/05/xojo-retinahidpi-the-journey-of-a-thousand-pixels/#comments
		
		
		Tue, 05 Apr 2016 00:00:00 +0000
				
		
		
		
		
		
		
		
		http://blogtemp.xojo.com/2016/04/05/xojo-retinahidpi-the-journey-of-a-thousand-pixels/

					
										“Retina” is the name for high resolution screens on Mac and iOS devices while “HiDPI” is the Windows equivalent. For simplicity, I’ll use HiDPI (which really is the universal technical term) for the rest of this blog post. Now that we have HiDPI support in Xojo, if you app doesn’t use any pictures, you can simply open your project, click on Shared under Build Settings and turn on the “Supports Retina/HiDPI” option. That’s all you need to do to have a HiDPI version of your app!

Having said that, if you are creating or using pictures in your project, there may be a few adjustments you’ll need to make to your code. A little over a year ago the process of making sure we had all of the necessary graphics together to build a Retina/HiDPI IDE was added to my to-do list. While 95% of the icons created for the Xojo IDE in 2013 already existed, most of the graphics that made up the IDE itself did not, and the IDE itself needed a bit of an overhaul to get it ready for the big change, both in graphics and in code…
Graphics
Since the Xojo framework didn’t have any HiDPI support yet, everything done last year was done brute force, that is, 2x images were loaded, scaled down by 50% and drawn where they belonged, just to make sure things would mostly line up correctly. While doing this did reveal the amount of work that we were in for, it also hid some issues that we ran into when the HiDPI-enabled frameworks started coming available this spring.
To give you an idea of the size of the task, there are a little over 1000 distinct icons and images used in the IDE today, of which ~370 we did not have a HiDPI version. Now while I like using programs like Photoshop® or Fireworks® for doing work like this, I wanted to transition our graphics to a vector drawing tool so that if/when a higher resolution screen is available, we’ll be able to go back to the originals and start from resolution-independent source-material. That said, we settled on using Bohemian Coding’s Sketch for the majority of the new graphics work. Total time to generate the missing images was about two man-months.
Code
Once the HiDPI-enabled frameworks started coming together, every place where a picture was being drawn needed to be audited (see why in the next section). This work took us from mid-December all the way through mid-March. I won’t tell you that it took two of us three full months of 60 hour weeks to accomplish, but it sure felt like it.
A couple of legacy coding issues came to light which would have to be resolved for everything to work right and I wanted to go over them just in case your projects don’t render correctly right off the bat. Let’s look at what’s changed.
Points vs. Pixels
This is by far the most common issue you’ll probably run into. Before Xojo had HiDPI support, a single element of color on a Picture and a single element of color on a Graphics object were exactly the same thing, pixel for pixel.. If your code looked like this:
Dim p As New Picture(100, 100)
Dim g as Graphics = p.Graphics
Dim widthPic as Integer = p.Width
Dim widthGraphics as Integer = g.Width
both widthPic and widthGraphics would have values of 100.
Now with HiDPI turned on, Picture coordinates and Graphics coordinates can be different from one another if the scale factor of the screen is greater than one. If you were to change the code above to:

Dim p As TrueWindow.BitmapForCaching(100, 100)
Dim g as Graphics = p.Graphics
Dim widthPic as Integer = p.Width
Dim widthGraphics as Integer = g.Width
Note: The BitmapForCaching method creates an image that has the right number of pixels and the right scale factor so you can just draw to it the way you always have and have everything still work exactly the same.

The value of widthPic will differ depending on whether your application is running on a HiDPI screen or not:




widthPic
widthGraphics


Normal
100
100


HiDPI
200
100



…and this is where the trouble begins because the number of physical pixels has actually doubled (in both directions, by the way) while the width and height of the Graphics object still reflect the original dimensions. The difference between these values is the scale factor of the screen you are drawing to.
Now, if you consider that Picture.Width and Graphics.Width have been interchangeable until now, you can see that this can cause a bit of a problem. When drawing to the Graphics object, you need to be working in Graphics pixels, not Picture pixels:
Dim p As TrueWindow.BitmapForCaching(100, 100)
Dim g as Graphics = p.Graphics
Dim widthPic as Integer = p.Width
Dim widthGraphics as Integer = g.Width
g.ForeColor = &cFF0000
g.DrawOval(0, 0, g.Width, g.Height) // Correct
g.DrawOval(0, 0, p.Width, p.Height) // This will draw too large
To wrap up this already long story, make sure all of your drawing routines are using coordinates relative to the Graphics object.
If right about now you’re wondering what we were smoking when this decision was made, rest assured that it was discussed for a long time and the overwhelming driving force was to maintain backward compatibility. With things set up this way you can still draw it onto a Graphics object created with the HiDPI framework and it should just work!
Immutable Pictures
Another hurdle you’ll undoubtedly encounter is the fact that multiresolution images are not inherently editable. This allows the framework to be more intelligent about loading and unloading images at runtime. This affects Image objects created in the IDE as well as ones created in code using the new Picture Constructor API. The most obvious effect is that you can’t draw directly to these images any more and the Graphics and RGBSurface properties will be Nil. If you need the ability to draw onto a picture via its Graphics property, draw the image onto a Picture created in code and work from that – don’t forget to copy the scale properties!
Nested Drawing
If your application creates pictures, and draws other pictures and clips into it using several levels of nesting, make sure you start from the top level when refactoring your code. You’ll find any compounded scaling errors much earlier this way, but you’ll also run a much smaller risk of creating issues that will only manifest when you go back and fix the top level drawing routines.
Drawing Without Context
For most of you, your drawing code will be directly in the Paint event of a Canvas and the Graphics object passed to the event already has all of the information that you need to succeed. In addition, you can always get a mutable picture that is all set up for the current screen by calling the new Window.BitmapForCaching method. This method is available from any RectControl, Window or ContainerControl subclass using TrueWindow.BitmapForCaching.
If (for some reason) you don’t have access to a window from your code, you can create a HiDPI image from a Graphics context by using the new ScaleX and ScaleY properties to set things up. For consistency, we created an extends method in a module like this:
Function BitmapForCaching(Extends g as Graphics, Width as Integer,  Height as Integer) As Picture
  Dim p as New Picture(Width * g.ScaleX, Height * g.ScaleY)
  // Set the appropriate resolution
  p.HorizontalResolution = 72 * g.ScaleX
  p.VerticalResolution = 72 * g.ScaleY

  // Set the scale factor so drawing to it will be correct
  p.Graphics.ScaleX = g.ScaleX
  p.Graphics.ScaleY = g.ScaleY

  // Very important to remember the mask!
  p.Mask.Graphics.ScaleX = g.ScaleX
  p.Mask.Graphics.ScaleY = g.ScaleY

  // Return the new picture
  Return p
End Function
If neither a Window nor a Graphics context is available, you can always create a multi-representation picture and leave it up to the framework to choose the right one when the image is being drawn to a Window, like this:
Dim pa() as Picture
Dim p1 as new Picture(100, 100)
p1.Graphics.DrawOval(0, 0, 100, 100)
pa.append p1

Dim p2 as New Picture(200, 200)
p2.Graphics.DrawOval(0, 0, 200, 200)
pa.append p2

Dim RetinaPicture as New Picture(100, 100, pa)
You’ll have to draw everything twice, so I suggest caching these images so you don’t need to do this more than once, especially if your drawing code is complicated. You can use a similar technique to load images from disk:
Dim pa() as Picture
Dim f as Folderitem = GetFolderItem("Test.png")
Dim pic as Picture = Picture.Open(f)
pa.append pic

f = GetFolderItem("Test@2x.png")
pic = Picture.Open(f)
pa.append pic

Dim RetinaPicture as New Picture(100, 100, pa)
Just remember that the images passed into this form of the Picture.Constructor must all have exactly the same aspect ratio or the framework will throw an InvalidArgumentException!
Conclusion
We’re looking forward to seeing all of your apps become HiDPI-aware and hearing about your experiences. I hope that our experience and suggestions make your transition just a little bit easier!

 
Read more: Advanced Retina/HiDPI: BitmapForCatching and ScaleFactorChanged
]]>
					
					https://blog.xojo.com/2016/04/05/xojo-retinahidpi-the-journey-of-a-thousand-pixels/feed/
			2
		
		
			
		
		
		https://blog.xojo.com/2015/12/08/o-retina-retina-wherefore-art-thou-retina/
		
		
		Tue, 08 Dec 2015 00:00:00 +0000
				
		
		
		
		
		
		
		http://blogtemp.xojo.com/2015/12/08/o-retina-retina-wherefore-art-thou-retina/

					
										During my keynote address last April at XDC, the Xojo Developer Conference, I said that we would be adding Retina support (the OS X feature that provides for ultra-high resolution displays) to the OS X framework in the 4th quarter of this year. We have been working very hard on Retina support both for the OS X framework and for the IDE itself. We didn’t want to stop there though. Windows also supports ultra-high resolution displays. For Windows, this technology is called HiDPI. Xojo is a cross-platform tool so we decided we should support both Retina and HiDPI, and do it in such a way that you don’t have to do much of anything and they just work.

UPDATE: Xojo Retina is here, April 2016

This bigger feature set of course takes a bit longer. We were hoping to ship it in 2015r4 this month but that’s not going to happen. There’s simply not enough time to test Retina/HiDPI support well enough to satisfy us. Instead, this feature along with a Retina/HiDPI-enabled Xojo IDE will come in 2016r1.
There will still be a 2015r4 release. We’ve been squashing bugs as we always do and we’ll get Xojo 2015r4 into your hands this month so you can have an even more robust base upon which to build your apps.
No one likes waiting, but the year is almost over and 2016r1 will be here before you can say Remote Debugger! OK, maybe not quite that fast but soon enough. 
From all of us at Xojo, Inc. we thank you for your continued support and we wish you and yours Happy Holidays.
]]>