OSDev.org

Posted: **Wed Dec 07, 2005 4:44 am**

Candy wrote: My guess:

- blit line horz (x,new-x,y,array of bits)

see GraphicalInterpreter

Using that, drawing a flat 'button' (assuming GC already set up properly and text as current item) would be

Code: Select all

FILL
IMM <border width>
ISPLIT
CLEAR
IMM <padding>
ISPLIT
DRAW <font-renderer>

Immediate values could be resolved from a 'theme database' at bytecode reception (e.g. the application says 'font renderer' and the bytecode will carry a tag to identify that). That means we can change the theme anytime (maybe it will just require to re-import some bytecode), and the application blissfully ignores it

Posted: **Wed Dec 07, 2005 5:34 am**

Pype.Clicker wrote: I wouldn't go for pure flash mainly because of macromedia licensing issues.

Sure, the talk was just about something 'flash-alike'.

Pype.Clicker wrote: okay, i better understand your point now, at least if "to split" means "to make distinction between", and not "to implement in two different servers". Nothing but the GUI server is going to need the display server, so it'd be a bit odd to have them separated in code, even if they're different beast regarding design.

Well, I meant that there are two seperate servers running simultaneously, and the thing that drove me to that idea was the 'media-player-issue' again: Apps which can't utilize the user forms and controls which are provided by the GUI server should just acquire a 'display handle' or something, and then send the drawing commands directly to the display server.

cheers Joe

OSDev.org

Direct Rendering

Re:Direct Rendering

Re:Direct Rendering