Home » Developing U++ » U++ Developers corner » Porting SystemDraw to Frambuffer
| 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: 13975
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: 13975
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: 13975
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: Fri Apr 26 13:10:48 CEST 2024
Total time taken to generate the page: 0.05512 seconds
|
Members
Pages
Help
Register
Login
Home
