Home » Developing U++ » U++ Developers corner » Porting SystemDraw to Frambuffer
| Porting SystemDraw to Frambuffer [message #22966] |
Thu, 03 September 2009 11:18  |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
Hi there,
SystemDraw has been there for a bit of time now, but it's only implemented for the major backends, Win32 and X11 on linux.
beeing on linux embedded, one often has no X11, so bare /dev/fb0 is what we have. no problem though, one might start at that point.
so my intention is here to port the SystemDraw layer (of which i have no pretty clue for now) to the famous framebuffer.
now here is the problem, i might need to look around for quite a time in the code, finding out which are the vital parts of the SystemDraw, and where to settle to write to fb.
If you could simply give a short overview of how SystemDraw is logically set up, meaning what is layer down to device, what is facing U++ layer.. so i know where i am. not filtering unneeded function in the code wasting time.
Or is there a (even short) description of the SystemDraw class..
So far i have understood that the class is splitet itself in 2 parts, beeind the destination draw for the GUI, and using some function to update data in the destinated layer, well, thats quite logical.
any help greatly welcome, or even if anyone has started already, i might join.
saludos
kostah
|
|
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #22979 is a reply to message #22967] |
Fri, 04 September 2009 12:06  |
 |
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Thu, 03 September 2009 05:26 |
an idea came along..
i'd need a bunch of drawing operations, which already are there, in the ImageDraw stuff.
so we might take a step to use an ImageDraw, somehow opening /dev/fb0 and using that one as SystemDraw, so we would have a single window application, nevermind  , no problem, thats a start
|
Nope, you need Painter, more specifically BufferPainter.
fb support is one of areas I would like to investigate. I have a very stupid question:
Is it possible to somehow develop fb application in X11 environment? I mean, how do I activate fb from X11 so that I can see results?
Mirek
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #22980 is a reply to message #22979] |
Fri, 04 September 2009 13:55 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
hi mirek
the point is that we *dont* use X11, so we work on bare /dev/fb0 and drivers (/dev/input/* or dev/mouse and even tslib stuff for touchscreen) to get that working..
now the drivers integration is part of its own, but displaying only, that is sommewaht part of Draw.
so i simply open /dev/fb0 within BufferPainter and have my Draw interface to that?. i think we might need an extra buffer painter here, fb0 is somewhat more complicated
you "simply" open /dev/fb0, but you then mmap it to your userspace and can then start painting on it (some more details on that needed). to find out mode or to set it, to find out strides, color witdth and the like there is this fbinfo struct (donno the name exactly, must look it up also) and according to that, BufferPainter needs to be set up. So maybe a wrapper class?
now the question arising is, where do you really set up the global or static first Ctrl, TopWindow or the like, which is base for all what CtrlCore is doing in the gui, including showing other control? i dont speak of windowing, its part of OS, but as far as i understood (looking up Win32 implementation of CtrlCore stuff) there somewhere mus be the point where a Topwindow or a SystemDraw is instantiated and drawn to GDC and passed all the events to.
Where is that point exactly, i could find it seen thing like CreateWindow and CreateWindowEx, but the rest.... thats kind of specific.. i wanted to know where the start point for Upp actually begins, where OS things switch /hand over to Upp stuff/interface.
as a startpoint we might want to take a look at the nanox project in blackfin uClinux trunk, here is the start point maybe, how to use fb0 (in a simple way, nanox is smalles X11, but we might want to have no X11 at all.
svn: blackfin.uclinux.org, svn of uClinux distro
trunk/user/microwindow/src/nanox/clientfb.c
dig for /dev/fb0
http://blackfin.uclinux.org/gf/project/uclinux-dist/scmsvn/? action=browse&path=%2Ftrunk%2Fuser%2Fmicrowin%2Fsrc%2Fna nox%2Fclientfb.c&view=markup&revision=7547
another Point: SDL
i saw that SDL is sowhat supported, how's that? it can use bare fb0 and also has its layer to the input driver stuff, including touch screen. does Upp support SDL natively?? meaning without any GTK stuff and the like? or even in windowss a native SDL?
native I mean making Upp *GUI* prjects that use no X or Win32 but SDL to display and interact.
I've seen that SDL can be compiled, but it actually only using Core stuff, so no Upp CtrlCore things, its simply compiling with the IDE and having benefit of Core, but we want more
that was quite a lot. sorry
|
|
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #22992 is a reply to message #22986] |
Fri, 04 September 2009 15:53 |
mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
| Mindtraveller wrote on Fri, 04 September 2009 14:40 |
Did I understand correctly that you try to create layer that enables writing POSIX GUI apps wthout need of X11?
(excuse me interfering this topic)
|
I would say partially that's what he's trying to do, except he's probably not worried about window manager itself, he needs that part inside window, i.e. drawing widgets + receiving events.
Moving/resizing/overlapping windows is maybe out of scope for him right now.
kostah:
The current status of SDL package is add-on, so you can add it to Core application, initialize the screen, and use ordinary SDL functions to draw something, but the CtrlCore is not aware of it at all.
edit: and due to licensing of SDL I'm not sure it's possible to integrate it into base U++ libs so tightly.
I think Mirek would rather opt for custom U++ FrameBufferPaint back-end (under BSD license), but I'm not sure if it fits into his development budget, there's never enough time to do everything you would like to.
[Updated on: Fri, 04 September 2009 15:57] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #22996 is a reply to message #22995] |
Fri, 04 September 2009 18:47 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
hi people
to make me understand:
in embedded systems, you often have no X11 or DirectFb (although there is a small port nxlib for the Blackfin uClinux). all what we have is frambuffer and input drivers.
so the need is only to run *1* single application, without windowmanager, just as a simple control gui for things to do on an embedded system. so frambuffer / input drivers should be enough, so we could spare out all the complex layers, making an embedded system slow and using large memory chunks (in fact thats the biggest concern in ES). using other intermediate layers like DirectFB or SDL, which give you abstract access to fb0 and input drivers is fine and comfortable, but also brings in some costs (regardless of licence, this is another concern as well).
i hope you got the picture..
in any case, we need a layer for the CtrlCore that either can draw on /dev/fb0 and get its input from /dev/input/* or a layer for CtrlCore to interact with SDL or DirectFB..
The graphic stuff is far complex, and the layering especially under linux is of its own, i.e SDL itself can run on DirectFB or bare Framebuffer, DirectFB can run on X or DirectFB or others...but you know all that already.
like you already got the point, SDL is just able to be build and used under Upp, but only for Core (not CtrlCore) base Applications, means not Upp native GUI applications, simple Console applications or so..
so what would be the best / easiest / most flexible solution to drop the X11/Win32 chains ??
Application layer like that is meant to be:
Upp GUI application (single window normally, one TopWindow instance)
||
output==================input
|| ||
framebuffer inputdrivers
or like that
Upp GUI App (real CtrlCore)
||
SDL
||
output======================intput
|| ||
(frambuffer, X, GL,Dir.FB) (/dev/input or touchscreen, or X11..)
or like that
Upp GUI App (real CtrlCore)
||
DirectFB
||
output======================intput
|| ||
(frambuffer, X, GL..) (/dev/input or touchscreen, or X11..)
or like that
Upp GUI App
||(native X11 layer)
nanox (former MicroWindows)
||
output======================intput
|| ||
(frambuffer) (/dev/input or touchscreen)
|
|
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #22998 is a reply to message #22980] |
Fri, 04 September 2009 18:53 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Fri, 04 September 2009 07:55 |
hi mirek
the point is that we *dont* use X11, so we work on bare /dev/fb0 and drivers (/dev/input/* or dev/mouse and even tslib stuff for touchscreen) to get that working..
|
I am asking because of development/debugging environment...
| Quote: |
you "simply" open /dev/fb0, but you then mmap it to your userspace and can then start painting on it (some more details on that needed). to find out mode or to set it, to find out strides, color witdth and the like there is this fbinfo struct (donno the name exactly, must look it up also) and according to that, BufferPainter needs to be set up. So maybe a wrapper class?
|
I think you are going to do double-buffering anyway, so ImageBuffer is just fine for this (as you can solve the format difference later...)
| Quote: |
where a SystemDraw is instantiated and drawn to GDC and passed all the events to.
|
It is during handling of WM_PAINT (or expose).
| Quote: |
Where is that point exactly, i could find it seen thing like CreateWindow and CreateWindowEx, but the rest.... thats kind of specific.. i wanted to know where the start point for Upp actually begins, where OS things switch /hand over to Upp stuff/interface.
as a startpoint we might want to take a look at the nanox project in blackfin uClinux trunk, here is the start point maybe, how to use fb0 (in a simple way, nanox is smalles X11, but we might want to have no X11 at all.
svn: blackfin.uclinux.org, svn of uClinux distro
trunk/user/microwindow/src/nanox/clientfb.c
dig for /dev/fb0
|
Well, thinking about it, I guess nice and simple solution is to provide some abstraction level...
I mean, a class that abstractly represents sort of framebuffer and mouse and keyboard input and then build the whole thing above it.
For development purposes, we can use normal single window to emulate this.
| Quote: |
another Point: SDL
i saw that SDL is sowhat supported, how's that?
|
Not realy, the only support is that it comes with mingw version.
| Quote: |
it can use bare fb0 and also has its layer to the input driver stuff, including touch screen. does Upp support SDL natively?? meaning without any GTK stuff and the like? or even in windowss a native SDL?
|
No. But I guess we can use SDL as inspiration for above abstraction layer...
Mirek
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #23997 is a reply to message #22998] |
Wed, 16 December 2009 11:19 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
Ok, people, this framebuffer topic is about to have a revival.
since we have the Painter stuff now and the headless drawing, and even the Docking facilities in bazaar, we almost have a "window manager".. but I need help 
I have started to prepare some porting stubs for the use of framebuffer in the CtrlCore. Well, for now, ist really stubs, just moslty plain copy and paste from X11 code (which lies next), and commenting doubtable or unneeded/unneccessary parts away.
i realized that the underlying interface is quite "distributed" over a lot of sections, without explicit "tagging" what is what. it'd be esier to have the commen interface functions somehow grouped, so one could know, these functions are required. current situation is that its pretty mixed with the helper functions for the apropriate interface as well. both, in headers and code. so this is maybe to be reorganised, especially if we take in account, that this might not be the last porting we face (next important would be to port to apple graphics), and there will be even more i think. so we need to make things clearer here. (at least a short description on what so far is used by both interfaces WIN32/X11 and is required in any other port, and what are their interface specific helpers, and maybe a sentence of description to each, especially when it comes to Clipboard,DragandDrop and the like).
back to topic.
base idea:
using /dev/fb0 to display the one and only (no window manager) TopWindow instance of an application (naturally fullscreen), which is driven directly by user input extracted from /dev/input layer
class
SystemDraw : public BufferPainter
where the BufferPainter can be initialized with an ImageBuffer
which in turn should somehow represent the /dev/fb0.
-->problem: the fb0 can have really weired dimensions, bitwisths per color, strides and the like..is the ImageBuffer capable to cope with that? or do we need to have the double buffering as only solution (where the normal ImageBuffer 24bit is overlayed/calculated on tob of the weired fb0 layout)?
the control input section should be driven directly with /dev/input/, this normally does invoke a repaint in some sort
we need to provide a full implementation of own drag and drop, which can be significantly simpler i think, because we dont drag between multiple windows od Win32/X11, but simply inside the TopWindow (which is between Ctrls)
we need to provide a full replacement for Clipboard stuff, how does this work?
we need to provide a full replacement of the TimerThread (which is used heavily by Ctrls, it also needs to be reentrant (means a new occurance of timer event is handled either by interrupting a possibly currently still working timerthread procedure, or by spawning another thread to handle this, which leads either to application lock (due to repeated reentrance) or to thread explosion if handling callbacks are misdimensioned somehow.
The GUI thread (which is the main thread) would be far the simplest part i think, cause it creates, opens and runs the TopWindow and realizes all the drawing and user input.
is there any description (besides the code itself ) available in terms of how Clip, Drag and Drop, the timer thread and the GUI thread are set up (basic ideas should be enough)
the GUI flag, which is used currently can be abandoned maybe, because it is evaluated only in POSIX environment, in WIN32 GUI is somewhat implicit, as soon as one uses the package CtrlCore, one uses gui stuff in Win32. in Linux, one should be able to specify GUI X11 or GUI FB somehow.. but this is small peanuts. backwards compatibility can be done imlicitly by defining a standard flag.
the stubs (NOT implementations) are half way done, as soon as it compiles and links, i will post it here, maybe mirek can take a look over it and clean out what he dooms or claims not neccessary (since i have no much idea of underlying gui facility) and maybe already integrate it in the trunk, to be able to code parallely. first thing woul be, of corse, to open the /dev/fb0 and display the main window once...
ok, till then, cheers
PS: maybe we can really use this effort to restruct code to make porting in future a lot esier.
PSS: sorry for the text chunk
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #24000 is a reply to message #23997] |
Wed, 16 December 2009 14:37 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Wed, 16 December 2009 05:19 |
where the BufferPainter can be initialized with an ImageBuffer
which in turn should somehow represent the /dev/fb0.
-->problem: the fb0 can have really weired dimensions, bitwisths per color, strides and the like..is the ImageBuffer capable to cope with that?
|
No.
| Quote: |
or do we need to have the double buffering as only solution (where the normal ImageBuffer 24bit is overlayed/calculated on tob of the weired fb0 layout)?
|
Yes. BTW, ImageBuffer is 32bit RGBA.
| Quote: |
we need to provide a full implementation of own drag and drop, which can be significantly simpler i think, because we dont drag between multiple windows od Win32/X11, but simply inside the TopWindow (which is between Ctrls)
we need to provide a full replacement for Clipboard stuff, how does this work?
|
IMO, it is in fact much easier to start from the scratch than implementing Clips in X11/Win32.
There is nothing magic, you have raw binary data and string that represents the type of data. Perhaps use filesystem to store both and you are done... (with clipboard anyway, D&D will need a bit more).
| Quote: |
we need to provide a full replacement of the TimerThread (which is used heavily by Ctrls, it also needs to be reentrant (means a new occurance of timer event is handled either by interrupting a possibly currently still working timerthread procedure, or by spawning another thread to handle this, which leads either to application lock (due to repeated reentrance) or to thread explosion if handling callbacks are misdimensioned somehow.
|
There is no TimerThread in CtrlCore And thing is pretty simple generally in fact. All you need to do is limit waiting for input events to some max timeout in message loop and to know current system time (one way or another). Then call TimerProc at the end of event processing or if there is timeout.
| Quote: |
is there any description (besides the code itself ) available in terms of how Clip, Drag and Drop, the timer thread and the GUI thread are set up (basic ideas should be enough)
|
I hope that above is helpful for starters, ask for more details as you go.
| Quote: |
the GUI flag, which is used currently can be abandoned maybe, because it is evaluated only in POSIX environment, in WIN32 GUI is somewhat implicit, as soon as one uses the package CtrlCore, one uses gui stuff in Win32.
|
GUI is because Win32 - console vs GUI apps have different linker options - that is the original problem.
| Quote: |
in Linux, one should be able to specify GUI X11 or GUI FB somehow.. but this is small peanuts. backwards compatibility can be done imlicitly by defining a standard flag.
|
Well, that is interesting problem I guess GUI FB and X11 as default or something like that.
| Quote: |
PS: maybe we can really use this effort to restruct code to make porting in future a lot esier.
|
Well, it is not so messy, but it is true that over those 10 years of development, thing are getting more and more patched.
Anyway, in reality, I am not huge believer of fresh starts there. If nothing else, it would put all of my apps in jeopardy...
Also, it is questionable that you can gain too much more clarity there. Some of stuff in CtrlCore is pretty nasty, but that is partly because host-platform details are pretty nasty too...
Mirek
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #24003 is a reply to message #24000] |
Wed, 16 December 2009 15:19 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
did i understand you right? there is no extra thread for the TimerProc in WIN32 or X11? (WIN32 used WM_TIMER as far as i know, ahh..which is ran by he same thread in spare times, when it sleeps and in X11 is maybe similar, right?
well, i'm learning.
your're right, platfomr stuff is a mess. so it's no wonder. actually i have learned a lot, how to have cleaner code because thanks to upp code. so its generally really clean, even fun to read, logical and short (most times)
thank you, i'll give it a try
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #24008 is a reply to message #22966] |
Wed, 16 December 2009 22:08 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
hi mirek, here comes the stubs for framebuffer environment. it should compile fine. is just the extract from my current svn tree (only the changed stuff left, simply replace)
flags situation:
GUI needs to be specified for FB only, if no backend follows, X11 is choosen automatically. (GUI X11). to compile frambuffer: GUI FB, WIN32 currently does not actively distinguish anything (besides what you mentioned).
i used X11 backend stuff as template, just tweaking as little as possible in first instance.
if possible, you could include this into trunk uppsrc, it comes with full .svn backend, so you can backcheck svn diff, but it mostly is things like extending #ifdef PLATFORM_X11 to #if defined(PLATFORM_X11) || defined(PLATFORM_FB) and the like.
the stubs, which were demanded during compile or linking have been prepared so far commenting code with
#ifdef UNUSED
...
#endif
next step i will try to prepare the TopWindow thing opening the /dev/fb0 and maybe painting a first picture. this could take a bit.
a branch would be good.. so i dont bother you to often, if you prefer
thanks for help
|
|
|
|
|
|
|
|
| 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 . 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
|
|
|
|
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #27229 is a reply to message #27228] |
Tue, 06 July 2010 10:13 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
| Quote: |
compile as "NOGTK" and get default, non-OS dependent, look&feel.
|
thats great..., i already have specified NOGTK flag when selecting FB, so its goot to know that was right
| Quote: |
there should be something like "FB" flag
|
i already have previsted something like that, flags: GUI X11 for current linux stuff, GUI FB for framebuffer stuff, with fallback option, if nothing else specified, GUI defaults to GUI X11, so no package breaks
| Quote: |
the whole framebuffer "backend" should be virtualized, so that you can easily bind U++ to any sort of device (framebuffer, SDL...).
|
dont quite get you here. frame buffer cant be "virtualized", its a backaned like the others as well, with its own SystemDraw, input parsing queue, timer procedure etc.. could you explain?
btw: SDL should be a port of its own. ofcorse, then, you can run upp on framebuffer as well, because SDL runs on framebuffer as well, but upp wont know about framebuffer..
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #27253 is a reply to message #27229] |
Thu, 08 July 2010 10:30 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Tue, 06 July 2010 04:13 |
| Quote: |
compile as "NOGTK" and get default, non-OS dependent, look&feel.
|
thats great..., i already have specified NOGTK flag when selecting FB, so its goot to know that was right
| Quote: |
there should be something like "FB" flag
|
i already have previsted something like that, flags: GUI X11 for current linux stuff, GUI FB for framebuffer stuff, with fallback option, if nothing else specified, GUI defaults to GUI X11, so no package breaks
| Quote: |
the whole framebuffer "backend" should be virtualized, so that you can easily bind U++ to any sort of device (framebuffer, SDL...).
|
dont quite get you here. frame buffer cant be "virtualized", its a backaned like the others as well, with its own SystemDraw, input parsing queue, timer procedure etc.. could you explain?
|
All these 'details' can be expressed by a bunch of virtual methods (very simplified said).
Later you take these and bind U++ to SDL or framebuffer or whatever else.
|
|
|
|
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #27256 is a reply to message #27255] |
Thu, 08 July 2010 11:36 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
i'll try to..
| Quote: |
whole framebuffer "backend" should be virtualized, so that you can easily bind U++ to any sort of device (framebuffer, SDL...).
|
well, SDL is in fact not quite the same as simply framebuffer and /dev/input, its more sort of X11, you allocate a SDL_Surface, and need to process input events..
as far as got through that whole thing, SystemDraw is the implementation is draw backend and DoMouse & DispatchKey are already backends... to these i tried to connect.
so far i tried to sum up the whole WIN32 thing by runtime tracing in debugger: correct if i am wrong somewhere..
//////////////////////////////////////////////////////////// ////
SYSTEM BACKEND WIN32
win32 api current state and important stations, analyzing and tracking the GUI_APP_MAIN macro.
Ctrl::InitWin32(HINSTANCE hInstance)
init/ register der window classes and a seperate timer class, instantiating of timer class with lpfnWndProc = &Ctrl::UtilityProc; the window classes with lpfnWndProc = (WNDPROC)Ctrl::WndProc;, they are the message processors. calls to create windows are done with win function CreateWindow later.
void AppInitEnvironment__()
language and environment specific inits like charsets
GuiMainFn()
applications specific stuff, global intis, here, Run() of a TopWindow class should be called
TopWindow::Run()
basicly forwards to create the window class instances in Open() call, Show()s it and sets up the EventLoop() to run, which only exits when app quits. prepares the ctrl exit.
void TopWindow::Open()
creates the window instance using the Create() subsystem for the main window instance
void Ctrl::Create0(Ctrl::CreateBox *cr)
actually creates and shows the window instance with win32 OS means, sets up the drag and drop stuff and calls a first RefreshDeepLayout(), which triggers a WM_PAINT, which is processed in Ctrl::WndProc
LRESULT CALLBACK Ctrl::WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
takes care of processing WM_CREATE und WM_DESTROY, otherwise forwards to the hwnd specific Ctrl (mapping exists), which is a TopWindow ctrl.. forwards to the WindowProc of the Ctrl, which is virtual
LRESULT TopWindow::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
takes care of some minimal TopWindow specific stuff like close behaviour, then, forwards to Ctrl::WindowProc
LRESULT Ctrl::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
processes the win32 message queue messages, here comes in WM_PAINT, which uses a SystemDraw to paint the main / top Ctrl's area to the win32 GDC surface of the hWnd, here also comes in WM_'mousestuff' which forwards to DoMouse, which takes care of translating and delivering the messages to the ctrls. further, WM_'keystuff' comes in, which forwards to DispatchKey..
void Ctrl::EventLoop0(Ctrl *ctrl)
is called in Run() (via EventLoop) and returns when application is about to finish, basicly calls in a loop ProcessEvents() which calls ProcessEvent() which calls sProcessMSG()
void Ctrl::sProcessMSG(MSG& msg)
runs the win32 API typical TranslateMessage / DispatchMessage duo, which ends up calling WndProc and dispatching / evaluating messages
LRESULT CALLBACK Ctrl::UtilityProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
processes the WM_TIMER message. the timer is used to wake up the ProcessEvents stuff (TranslateMessage / DispatchMessage) which will also process what?? why does it need to wakeup? process the postcallbacks? becuse, user input and repaint stuff comes directly as WM_* messages, which wake up the queue as well
sorry for the long post, just need to clarify i dont miss things.
|
|
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #27259 is a reply to message #27258] |
Thu, 08 July 2010 15:41 |
|
|
| kohait00 wrote on Thu, 08 July 2010 15:07 |
about the timer thing i need some ideas
|
Hi Kohait,
What about bazaar/Timer? It is pretty universal and independent package, someone isolated it from CtrlCore for use in console apps (it depends only on core). Only problem might be that it requires MT (Is it really problem?).
| kohait00 wrote on Thu, 08 July 2010 15:07 |
Open() / Create()
ensures that only one TopWindow exists, sets fullscreen flag, makes first RefreshDeepLayout()
|
It might be easier (and even better) to not control how many TopWindows is opened. Just paint the topmost (the latest opened).
I really like the idea of U++ on framebuffer. Expect my help as far as my knowledge goes 
Bye, Honza
EDIT: Oh, now I see that bazaar/Timer is your work, so you probably already considered it So, what about using POSIX timers (timer_create, timer_settime etc.)? I'll have a closer look at it as soon as I get back to my linux computer (which is unfortunatelly not until next week  )
[Updated on: Thu, 08 July 2010 17:16] Report message to a moderator |
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #27260 is a reply to message #27259] |
Thu, 08 July 2010 17:25 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
hey dolik, thanks for help
i really considered using Timer, but it uses an extra thread.. well, what about apps compiled with GUI but *without* MT, they wont work..
i basicly thought of using the timer *queue*, executing it myself (means in the MainThread i call TimerProc in a loop)..thus i could PostCallback to it.
but: the TimerProc uses a fixed sleep intervall, 10 ms, when nothing is to be done..now when it sleeps, it sleeps hard. no way to wake it up before that time. this will affect responsiveness.
maybe i will neet to reimplement TimerProc, which will not sleep, but wait for some kind of wakeup signals, maybe select() stuff..
still in modeling phase
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #27261 is a reply to message #27256] |
Thu, 08 July 2010 17:55 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Thu, 08 July 2010 05:36 |
i'll try to..
| Quote: |
whole framebuffer "backend" should be virtualized, so that you can easily bind U++ to any sort of device (framebuffer, SDL...).
|
well, SDL is in fact not quite the same as simply framebuffer and /dev/input, its more sort of X11, you allocate a SDL_Surface, and need to process input events..
|
Which is exactly why I would attempt to make the whole framebuffer variant generic...
| Quote: |
LRESULT CALLBACK Ctrl::UtilityProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
processes the WM_TIMER message. the timer is used to wake up the ProcessEvents stuff (TranslateMessage / DispatchMessage) which will also process what?? why does it need to wakeup? process the postcallbacks? becuse, user input and repaint stuff comes directly as WM_* messages, which wake up the queue as well
sorry for the long post, just need to clarify i dont miss things.
|
Utility proc is Win32 implementation hack - we are using one special window (utilityHWND) to handle some Win32 messages that could not be handled otherwise. UtilityProc is its windows proc.
The rest you get right, however, it has little to do with planned framebuffer target.
Mirek
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #27270 is a reply to message #27269] |
Fri, 09 July 2010 14:42 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
| Quote: |
eventual conversion should be performed by framebuffer host virtualization
|
ofcorse, but it would be great to have some 'generic' bit bliting / stride copying functions in Painter / ImageBuffer, imagine all the weired graphics formats that could be exported with it. or is plugin/* the place for that?
[Updated on: Fri, 09 July 2010 14:42] Report message to a moderator |
|
|
|
| Re: Porting SystemDraw to Frambuffer [message #27271 is a reply to message #27270] |
Fri, 09 July 2010 16:44 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Fri, 09 July 2010 08:42 |
| Quote: |
eventual conversion should be performed by framebuffer host virtualization
|
ofcorse, but it would be great to have some 'generic' bit bliting / stride copying functions in Painter / ImageBuffer, imagine all the weired graphics formats that could be exported with it. or is plugin/* the place for that?
|
We already have it. See RasterFormat.
Mirek
[Updated on: Fri, 09 July 2010 16:59] Report message to a moderator |
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Tue Apr 28 13:34:47 GMT+2 2026
Total time taken to generate the page: 0.01258 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
