This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Display, VisualWorks and Flicker - Part 3
Feed Title: Pollock
Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml
Feed Description: Pollock - the next VW GUI
Ok, now we've got the basics, so let's cover some things that cause flicker, both "what you would expect" and some you wouldn't.
Let's take an example of one of the "you might expect that to cause flicker" cases in Pollock. Pollock's Grid allows you to specify the background cell color of any cell, as well as the foreground display color of any cell. This is unlike the ListBox or TreeView, which only let's you specify the overall background of the whole list (or tree)... even though it does allow you to specify the foreground color (and style) of each list item.
As is typical, I start with an example widget: A Grid that sits alone on a window that currently shows three columns and 20 rows, but has 1000 rows available to show above and below what is currently shown. Someone asks that Grid to page down. In other words, I have to repaint all of the rows and all of the columns that are visible (and only the ones that are visible... Pollock is smart enough to do that). Here's what happens.
Pollock basically rasters the painting, left to right, top to bottom. Since a Grid can NOT assume that the background color for each cell is the same color (unlike a ListBox or a TreeView), it has to display each cell, one at a time, first the background, then the widget in the cell (CheckBox, InputField/Label, DropDownList, etc.). Another feature of the Pollock Grid is that each column can say if it shows a column line (as well as being able to turn on/off column lines globally). Again, Pollock can't assume anything here, so after each cell is painted, it goes and draws any column lines for each column (but only for that row!) Yet Another feature of the Pollock Grid is that you can turn on or off row lines globally. So... Pollock finally draws a line below the cells for that row. BUT, it can't just draw a line from the left to the right of the whole visible Grid. Pollock has as yet another feature the ability to state if the last column should have visually unlimited length. In other words, if you turn this on, even if the last column only would normally extend to 80% of the width of the Grid, with this turned on, it would SEEM that the column filled the Grid all the way to the right edge. But that's not really an issue here, its just me showing off a nice feature.
With the above explanation, we see that there are 60 cell paints and for each row, an additional 3 column lines and a single row line. Now, let's apply additional features to our example. Let's say that the Grid is set up so that the background for each row is such that every third row has a white background starting with the first row. AND every third row has a light gray background for every third row starting with the second. AND every third row has a dark gray background for every third row staring with the third.
Further, let's say that it is set up such that every seventh cell in the second column has a red background. Also, that every ninth cell in the third column has a red background. In case you're wondering, yes, Pollock's Grid supports all of this. Finally, we'll say that every eleventh row is 30 pixels high, while all the rest are 25 high. Yes, this too is a feature of Pollock.
How can you optimize all of this drawing? Well, as you may see, you can't. No matter if you use Direct, Invalidate Now or Damage, all of those writes, take a bit of time. Not a lot. But because the backgrounds of each cell is changing and the plain fact that it may take 1/20 of a second (or more) to display all of these cells when there is so much to display in terms of colors and so on (yes, I did some testing), you can get some perceived flicker. Yes, it will be minor. Unfortunately, ANY flicker is perceived by the viewer as an irritation, no matter how minor. On top of that, we may get a bit more than we thought! This is because, unlike the people who do animation our displaying, whenever it is happening, happens whenever it wants. It is not synchronized with the display monitor in any way. There is no "only draw when the monitor is blanking for refresh."
In case you think I'm coming up with a very contrived example, you're right. Indeed, if you don't do any of the above background color tricks, the typical draw time for the same Grid is between 14 and 19 milliseconds. Unfortunately, the example is all about a complex user interface, not JUST a complex Grid. Also, more visible rows and columns means more time. Bottom line, some flicker is possible, and it's not even predictable when it will happen.
Now let's look at another basis for flicker that most don't expect. We'll take our Grid above, and make it so that it is set to have it's left edge 150 pixels to the left of the right edge of the window, no matter how big the window is, and the top to be 150 pixels up from the bottom edge of the window, again, no matter how big the window is. Finally, the right edge is set to the window's most right, and the bottom is set to the window's bottom. When we open this window, we'll start off with it being 200 x 200 in size. Then, let's resize the window it so that is 250 x 250.
Our Grid has moved on the window. It's original origin was 50 @ 50, and now it is at 100 @ 100. This means I have to repaint the background of the area where the Grid was as well as repainting the whole Grid. The facts on the ground are worse than we think. In fact we don't know where the Grid really was before the resize, once the resize is done, our Grid get's it coordinates from the existing world, and says "I'm Here!" Before you say "Well, make it know that, and just repaint that background," I need to point out "TANSTAAFL" (There Ain't No Such Thing As A Free Lunch, Robert Heinlein, The Moon Is A Harsh Mistress)
When you write a GUI framework, you can't know what will be. For instance, instead of having just a Grid, let's say that whenever the window gets bigger than 225 x 225, that the developer slaps a button immediately to the left of the Grid. For instance, instead of having the Grid stay hooked to the bottom right, it is set to actually get SMALLER as the window gets larger (this is actually fairly simple to do). Or the Grid and other widgets move around in other ways you can't imagine. Even though you hope that no one will do such things, they can. Thus, you can't assume jack squat.
So that leaves us with having to paint the whole background of the window, and then redrawing each widget. On windows, you have your gray or other colored window background, and then you have your typically white background Grid. Oh, and did I forget to say that these resizes come in as just Damage, and by the time we start repainting, we don't know that the cause of this particular request to display this widget is because of a resize? Sadly, this is true. So first the whole window gets painted gray or whatever color, and then the widgets on top of that. To paraphrase the late Mr. Rogers: "Can you say flicker? Good, I knew you could."
Next up, we'll talk about the existing facilities in Wrapper (an VisualWorks in general) to mitigate flicker, and their pros and cons.
Previous Topic
