Home   Archive   Permalink



GOB! vs SDL2 commands

Sharing my experiments while working on an SLD2 extension for R3.
    
The View implementation of R3 relies on GOB! Everything visible is appended to a root GOB! that is the window. At a lower level, GOB! are processed by C code and rendered depending of their 'type' (color, text, svg, ...).
When using View, there is a time to build the GOB! based structure (REBOL code) and a time to render this structure to the screen (C code).
    
With the SDL2 extension, drawing to the window (as well as creating the window) is made thru the extension commands. A data structure is not mandatory and some experiments could be done for a Model View Controller approach against a pure Parse based approach.
    
I wanted to make a little comparison between the existing GOB based solution and this SDL2 extension, so here, I created a window 1000x1000 size and filled with squares of 10x10 each of random color.
    
GOB based solution:
probe dt [
    for x-axis 0 1000 10 [
     for y-axis 0 1000 10 [
        append win g: make gob! [size: 10x10]
        g/offset: as-pair x-axis y-axis
        g/color: random 255.255.255
     ]
    ]
    probe dt [show win]
]
    
SDL2 extension solution:
probe dt [
    for x-axis 0 1000 10 [
     for y-axis 0 1000 10 [
        set-draw-color random 255.255.255
        draw-fill-rect as-pair x-axis y-axis 10x10
     ]
    ]
    refresh-screen
]
    
GOB! results:
speed: 20ms (show) 30ms (show + GOB structure)
memory: 9156k
    
SDL2ext results:
speed: 27ms
memory: 29132k
    
(tests performed on Windows7)
    
It's difficult to conclude anything as the speed and memory usage can differ from one scenario to another. The fact that GOB! are processed by C code is a plus. The SDL2 based solution consumes more memory, this memory seems to directly relate to the screen surface used.
    
A block 'similar' to the GOB structure could be given to the SDL2 extension in order to process the whole drawing at C level (to be investigated) but this will be in all cases be less convenient and flexible than Gob.
    
The motivation behind SDL2 extension is to bring a View-like to more platforms. This currently has been compiled and tested with no issues on OSX and Windows.
    
Another approach could be to plug the SDL2 behind GOB rendering, this would keep everything compatible.

posted by:   GregP       20-Mar-2015/5:42:50-7:00



Geomol (John) talked about working with SDL last week in Henrik's GUI thread about. Have you talked with him about coordinating your efforts?

posted by:   Nick       21-Mar-2015/8:09:42-7:00



Thanks for reporting this, I'll check again, I guess you talk about the VID Ext Kit on Altme?

posted by:   GregP       21-Mar-2015/8:59:52-7:00



A little update based on a higher "show" samples (1000), results in ms:
DRAW:     0.267
GOB:     0.21
SDL2 loop: 0.10
SDL2 gob: 0.11
    
I didn't know I could use GOBs from my SDL2 extension, so I added a show-gobs commands and tried. Surprisingly perfos are not better for this scenario.


posted by:   GregP       23-Mar-2015/12:01:57-7:00



For those who are interested, I have an experimental android branch that uses SDL for window management and event handling at: https://github.com/zsx/r3/commits/android
    
There are still a lot of things to do, but it's capable of running some simple GUI programs.

posted by:   Shixin       17-Apr-2015/14:04:04-7:00



I've been away from R3 since a few weeks but I'll look at this! Why not do the same for MacOSX?

posted by:   GregP       4-May-2015/15:41:42-7:00