U++ forum: Welcome to the forum

Re: Porting SystemDraw to Frambuffer [message #27146 is a reply to message #22966]

Mon, 28 June 2010 13:43

kohait00
Messages: 939
Registered: July 2009
Location: Germany

Experienced Contributor

hi all,

i've been busy with another project (which isnt done yet anyway, but it beats my nerves already Smile

. but now slightly i want to get back to this framebuffer issue.. over the past months a gained some amount of knowledge about upp, mirek and others are constantly providing extremely valuable infos and i start to wrap my mind on it (Painter, Draw, .. still in progress)

so here we go.. lets collect the things that will need to be adresses when porting. please complete what i forgot so the list could be used as a reference when wanting to port to other things (mac i.e.)

/////

* Drawing (open surface, check modes, alignment, color palette, implement Draw interface operations, TopWindow, DHCtrl ..)

for framebuffer this is more or less the base thing. a SystemDraw : BufferPainter which is directly doublebuffering to the /dev/fb0 with help of a converting function (which adresses strides/alignment issues). The Draw interface is completely implemented in BufferPainter.. TopWindow can only be one for framebuffer, in fullscreenmode.

* Input Interface (open input streams, /dev/input*, translate to Upp messaging, prepare for periodical invocations

* Timing (set up thread to invoke repaint each 10 ms or on demand, Timer Queue, PostCallback adaption

* Drag&Drop (this is probably the most complicated part, setup static infrastructure to mark things that are dragged??)

* Clipboard (also static infrastructure, buffers for text, images, etc..??)

* Fonts (any idea?)

* later, small "WindowManager" replacement, to be able to render / run more that one TopWindow

////

but still got some questions
what is the exact purpose / idea of:

1) TopWindow (create & startup a system dependant top window instance, linking its GDI to upp stuff as well as means to dispatch input messages. all other Ctrl's are placed as upp own children, not system own windows..)

2) DHCtrl (Ctrl with own GDI context??, seperately refreshable without affection other ctrls?? i found some in info in
http://www.ultimatepp.org/forum/index.php?t=msg&goto=267 38&
but i guess it wont be needed in frambuffer environment at first.

what more issues do we need to adress here? (maybe this could be sort of a porting guide...)

thanks

Report message to a moderator