Joe Ranieri – Xojo Programming Blog

Advanced Retina/HiDPI: BitmapForCaching and ScaleFactorChanged

Joe Ranieri — Thu, 07 Apr 2016 00:00:00 +0000

The most direct way to support HiDPI* for custom controls is to draw into the Graphics object passed into the Paint event. That graphics object is already configured with the appropriate scale factor and double buffering- the entire control will be handled correctly by the framework if the DoubleBuffer property is set.

*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

Speeding Up TextArea Modifications In OS X

Joe Ranieri — Mon, 28 Dec 2015 00:00:00 +0000

When doing a lot of manipulation to a TextArea’s contents under Cocoa, performance can suffer due to the underlying NSTextView doing work on layout and glyph selection. This can be sped up by telling the text view that you’re going to begin editing. You can do this by using a few Cocoa Declares.

The Declare statements are relatively simple:

Declare Function documentView Lib "AppKit" Selector "documentView" _
  ( obj As Integer ) As Integer
Declare Function textStorage Lib "AppKit" Selector "textStorage" _
  ( obj As Integer ) As Integer
Declare Sub beginEditing Lib "AppKit" Selector "beginEditing" _
  ( obj As Integer )
Declare Sub endEditing Lib "AppKit" Selector "endEditing" _
  ( obj As Integer )

These Declares give you access to methods for enabling “batch-editing mode” for the underlying NSTextView.

First, you want to get the text storage for the document, which is a two-step process. In the first step, you take the TextArea’s Handle property (an NSScrollView instance) and ask for its document view:

Dim docView As Integer
docView = documentView(MyTextArea.Handle)

Now you get the NSTextStorage for the NSTextView:

Dim storage As Integer
storage = textStorage(docView)

With the text storage, you can now enable batch-editing mode by calling beginEditing:

beginEditing(storage)

Now you can make your significant changes to the TextArea:

For i As Integer = 0 To 5000
 MyTextArea.AppendText("Lorem ipsum dolor sit amet. ")
Next

And when you are finished disable batch-editing mode:

endEditing(storage)

So how much does this improve performance? In my tests, the For loop by itself takes about 4.3 seconds to complete. Using batch-edit mode with these Declares drops it to 0.02 seconds. That’s almost instantaneous!

If you find you are going to use these Declare often, you can add them to a module as Extension methods so that you can call them more easily (as shown in the sample project):

Download Sample Project

Originally published on November 26, 2012 by Joe Ranieri

Testing The Compiler

Joe Ranieri — Wed, 17 Jun 2015 00:00:00 +0000

Over the course of the last year, there have been a huge number of changes to the Xojo compiler (just under 800 commits). We made large refactorings, like rewriting how unqualified name lookup works. We fixed around 35 bugs, some of them dating back years. We added major new features to the language, including ‘Using’, Iterators, and new data types. To top it all off, we shipped support for a completely new platform, iOS, and then met Apple’s deadline for building 64-bit iOS apps.

And after all of that, we ended up with around eight regressions in the compiler. While not the perfect zero, I think this is just as impressive as the changes themselves.

One of the biggest factors in the low regression rate is the compiler’s testing setup. For each bug we fix or feature we add, we create additional tests. Due to how the compiler is structured, not all parts can be tested, but we still added over a hundred tests in the course of the year.

The test suite itself is simply a collection of raw Xojo source files on disk. Each test case can have expectations, which specify what the compiler should emit for the line in terms of errors or warnings. The expectations are specified in specially-formatted comments inside of the script itself. The end result is that test cases are self-contained, play nicely with version control, and are easy to write (which is by far the most important factor).

Here’s a simple test case, which accompanied the fix for Feedback case #21462:

Function Pointless() As Object
  Return -Nil // expected-error 
End Function

Of course, not all test cases are quite so straightforward or short. For example, the test for Feedback case #34479 is over 200 lines long, due to the edge cases that were found while fixing it. There are also times where test cases have to be somewhat contorted:

Sub Foo(param As Int32, _ // no-error
        param As Int32) // expected-error 
End Sub

The test harness is a fairly simple Xojo console application. The harness recursively searches through the folder of test cases, executes the test via the XojoScript class, and compares the XojoScript results against expected results.

The expectations are extracted from the script via a simple parser that understands just enough of the Xojo language to read all of the comments. The compiler’s own functions were intentionally avoided because they are a fundamental part of what is being tested.

Overall, the test harness took about two weeks to write and polish off. The time spent was well worth it and I would encourage the use of automated testing, even if you can’t test every part of your product. Every bug that the test suite catches is one less bug that ends up in your customers’ hands.

Why are there diamonds in my user interface?

Joe Ranieri — Tue, 20 Aug 2013 00:00:00 +0000

You may have seen text that has strange diamond characters in it. If so, you likely have an encoding problem.

Fundamentally, Xojo strings are a series of bytes and a TextEncoding object that specifies how to interpret the bytes. It’s up to the programmer to make sure that the bytes are tagged with the correct TextEncoding object. You can do this using the DefineEncoding method or by passing in a TextEncoding parameter to various functions like BinaryStream.Read. Informally speaking, strings without an encoding are considered to be a simple “bag of bytes”, much like a MemoryBlock. Strings with a valid encoding are considered to be “textual” strings.

In the Xojo Cocoa framework, just about everything you see in the user interface, including drawing to a Graphics object or setting a TextArea’s Text property, requires a “textual” string. If the Xojo Cocoa framework needs a “textual” string but is passed a “bag of bytes” or a string that has a TextEncoding that isn’t correct for the bytes, it attempts to provide a fairly graceful fallback to avoid crashes. The fallback path tries its best to display something, which often means inserting the Unicode replacement character — the diamonds seen in the screenshot below:

The exact behavior of the fallback path might change over time, but it currently works like this:

If the string is marked as UTF-8 but isn’t valid UTF-8, the framework attempts to parse it as UTF-8 and replace any invalid sequences it finds with the Unicode replacement character.
If the string had no encoding or it was otherwise invalid, the framework treats the string as ASCII and replaces anything non-printable with the Unicode replacement character.

To avoid this fallback behavior, you just need to make sure that the encoding of your string is defined properly. If all your strings are defined within Xojo, then you are all set because they use UTF-8 by default. But if your strings come in from external files, Internet communication or databases you may need to specifically define (or convert) the encoding.