Sure. It's just a change to Pharo that a switch to Athens rendering could enable. You couldn't quite do the same thing in BitBlt / current Morphic as you would need three forms: one for rendering, one inactive one, and one active one. Switching to Athens would make the V-Sync thing be quite efficient as you wouldn't be copying large amount of bits from one form to another on a regular basis. Cheers, Jeff On Thu, Mar 27, 2014 at 5:09 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 March 2014 20:22, J.F. Rick <self@je77.com> wrote:
I've been using Athens to render my applications and I've thought a bit about how the #changed mechanism might change when BitBlt rendering is replaced by Athens rendering. First, you must realize that a lot of the rendering in Morphic is highly specialized to deal with the slowness of BitBlt rendering. So, a morph that has changed in appearance (by moving, etc.) calls the #changed message on itself. This tells morphic that it needs to get rerendered when the screen is next being updated. The full bounds of the morph are then added to the damage recorder. When the UI loop gets around to it, the damage areas are rerendered in a relatively smart fashion. For instance, if a morph is opaque, none of the morphs behind it get rendered. Only the damage rectangles are copied to the canvas, which is then updated.
With Athens, this strategy is problematic. Because Athens allows for arbitrary rotation and scaling, it is much more difficult to determine the bounds of a specific morph. Athens also can use local positioning as opposed to the global positioning currently used in Morphic. Igor argues that it is best not to try to figure this out but just to render everything when anything has changed. In my experience, that is a reasonable proposition. Athens rendering is fast enough that even full animation could be done reasonably. That would also simplify the #changed code and could pretty much eliminate the damage recorder.
OK. That's enough setup. Now for the suggestion. One problem I still have with Athens rendering is that there is still a visual artifact that has to do with the screen refresh not being in sync with the UI loop. Half the screen renders the previous frame and the other half renders the current frame. While it only is noticeable when moving something fast, it still isn't nice. So, here's the suggestion. Have two Athens surfaces in memory that switch between being the one next to be rendered and the active one. When the screen refresh comes along, send it to the last one rendered (i.e., the active one). When a change happens, render the surface on the inactive one. When that is done, make it the active one. Thus, the screen update always has an accurate form. It also would mean less copying around of forms (i.e., cacheing). I'm not sure if this implementation is viable, but it seems like a fairly efficient strategy that Athens could enable.
Right. This is something what called V-Sync. And all i can tell about it, that it is out of scope of Athens, because there's nothing in Athens API which tells where the results of drawing will be used: on screen, printed on paper, into file etc.. Dealing with it requires another device-specific layer which controls it, in our case - the layer responsible for delivering content to the screen. Apparently for such layer (if it will appear one day - like in OSWindow), it should be completely orthogonal, where content comes from: from Athens, BitBlt or other source(s).
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick