Home » Developing U++ » U++ Developers corner » Rainbow, first iteration
() 1 Vote
|
|
Re: Rainbow, first iteration [message #33160 is a reply to message #33081] |
Tue, 12 July 2011 11:31 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
Win32Gui.h:324
X11Gui.h:227
void DrawDragRect(SystemDraw& w, const Rect& rect1, const Rect& rect2, const Rect& clip, int n,
Color color, uint64 pattern);
need to be added, otherwise it prevents rainbow/Paint from commpiling with GUI only. how should that be treaded generally? is this considered a 'to be implemented' function?
my goal is to have a bunch of backends to choose from, while developing can go GUI only, later one switches to GUI LINUXFB..
what about a meta package wihich incorporates all backends? so one only needs to add that one..it has the right flag switches set already..
@mirek: especcially for Framebuffer: could you summerize in short your thoughts/strategy on designning the FB* interface (FBInit, FBFlush.. etc)
[Updated on: Tue, 12 July 2011 11:36] Report message to a moderator
|
|
|
Re: Rainbow, first iteration [message #33166 is a reply to message #33160] |
Tue, 12 July 2011 15:04 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Tue, 12 July 2011 05:31 | Win32Gui.h:324
X11Gui.h:227
void DrawDragRect(SystemDraw& w, const Rect& rect1, const Rect& rect2, const Rect& clip, int n,
Color color, uint64 pattern);
need to be added, otherwise it prevents rainbow/Paint from commpiling with GUI only. how should that be treaded generally? is this considered a 'to be implemented' function?
|
...well, DrawDragRect is "under development" now, caused me some troubles (some indirectly). Interface is changing because of framebuffer, it shall be "to be implemented" function but with different signature.
Quote: |
my goal is to have a bunch of backends to choose from, while developing can go GUI only, later one switches to GUI LINUXFB..
|
Yes.
Quote: |
what about a meta package wihich incorporates all backends? so one only needs to add that one..it has the right flag switches set already..
|
Well, maybe. Do not consider this that important now. It is easy
to add required FB backends to the project.
Quote: |
@mirek: especcially for Framebuffer: could you summerize in short your thoughts/strategy on designning the FB* interface (FBInit, FBFlush.. etc)
|
Anything specific?
I have to say some things are still changing..
Mirek
|
|
|
Re: Rainbow, first iteration [message #33167 is a reply to message #33166] |
Tue, 12 July 2011 15:46 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
especially FBUpdate and FBFlush, when exactly are they called and what exactly are they supposed to do? i could guess from the names but it's not specific, i'll try to summerize in brief what i have found out so far:
Framebuffer is performing its drawing of the controls to a BufferPainter, whoose content can then be bitblitted to the real framebuffer. (what are the other ImageDraw, BackDraw etc.)
Framebuffer expects / calls some functions to help finish that process. it also expects the real backend to generate / derive the events/messages from your underlying hardware.
FBUpdate: reports the area that should directly be repainted / transfered to the underlying hardware framebuffer corresponding area, or should it schedule some kind of writeback..?
FBFlush: should it transfer everything (the entire area) from Ctrl::GetFrameBuffer to the underlying framebuffer section? is this not obsolete and could be done with FBUpdate(EntireSize)? Or does it work as a FBCommit after several FBUpdate calls? in this case, when FBUpdate directly memcpy's to the real framebuffer, no commit is needed, and FBFlush can remain {}
FBEndsession(): is this the means to signal to the Framebuffer package that the app wants to quit? (especially when there is one bare application, means no SDL or sth. there is no other means)? since SDL has the SDL_QUIT, which could map to the bool *quit flag from ProcessEvent.
FBSleep: ideally, this should sleep a fixed granularity of time, say 10ms, but be 'cancelable' or 'expireable' on arrival of new events to process.. if this is not possible, simply Sleep(10)?
FBIsWaitingEvent: should determine in a nonblocking manner, if there are messages or events to be processed. this is called in advance, prior to FBProcessEvent, which is called if messages/events to process really do exist. if there is no means to determine if events are there, simply return always true?
FBProcessEvent: here, *one single* backend message/event per call is dequeued and dispatched to upp understandable messages/events, using some custom translation mechanism..
but there are more things one needs to implement:
bool GetShift() { uint8* ka = SDL_GetKeyState(NULL); return ka[SDLK_LSHIFT] || ka[SDLK_RSHIFT]; }
bool GetCtrl() { uint8* ka = SDL_GetKeyState(NULL); return ka[SDLK_LCTRL] || ka[SDLK_RCTRL]; }
bool GetAlt() { uint8* ka = SDL_GetKeyState(NULL); return ka[SDLK_LALT] || ka[SDLK_RALT]; }
bool GetCapsLock() { uint8* ka = SDL_GetKeyState(NULL); return ka[SDLK_CAPSLOCK]; }
bool GetMouseLeft() { return (SDL_GetMouseState(NULL,NULL) & SDL_BUTTON(SDL_BUTTON_LEFT)); }
bool GetMouseRight() { return (SDL_GetMouseState(NULL,NULL) & SDL_BUTTON(SDL_BUTTON_RIGHT)); }
bool GetMouseMiddle() { return (SDL_GetMouseState(NULL,NULL) & SDL_BUTTON(SDL_BUTTON_MIDDLE)); }
the Keys.h assignments, for K_* of upp, caution, it uses some special structure, K_ALT and K_ALT_KEY are not the same..
one does normally NOT need to define the starting point of the application (done in Framebuffer), but can override it (see SDLFb)
[Updated on: Tue, 12 July 2011 15:48] Report message to a moderator
|
|
|
Re: Rainbow, first iteration [message #33169 is a reply to message #33167] |
Tue, 12 July 2011 18:02 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Tue, 12 July 2011 09:46 | especially FBUpdate and FBFlush, when exactly are they called and what exactly are they supposed to do?
|
Well, unfortunately, meanings are not yet 100% fixed, as I am still solving some issues with mouse cursor fluidity, but actual broad meaning is:
FBUpdate - tell that some portion of framebuffer is to be moved to the screen. At the moment, it is not required nor prohibited that the update happens immediately.
FBFlush - at the end of function, all previous FBUpdate should be visible on the screen. If they are moved by FBUpdate, FBFlush can be NOP.
Quote: |
Framebuffer is performing its drawing of the controls to a BufferPainter, whoose content can then be bitblitted to the real framebuffer.
|
Yes.
Quote: |
(what are the other ImageDraw
|
Provides means for widget to draw on its view area directly (without Refresh/Paint).
Not used for Framebuffer; on system with direct painting, it is used when BackPaint mode is active (to provide backbuffer).
Quote: |
Framebuffer expects / calls some functions to help finish that process.
|
Yes.
Quote: |
it also expects the real backend to generate / derive the events/messages from your underlying hardware.
|
Yes, as part of event processing.
Quote: |
FBEndsession(): is this the means to signal to the Framebuffer package that the app wants to quit?
|
No, it is basically means that GUI is to be shut down (e.g. computer switched off).
Of course, if we run "windowed fb", then equivalent is closing the host window.
BTW, dealing with end-session event is somewhat unfinished bussiness in U++...
Quote: |
FBSleep: ideally, this should sleep a fixed granularity of time, say 10ms, but be 'cancelable' or 'expireable' on arrival of new events to process.. if this is not possible, simply Sleep(10)?
|
Yes.
Quote: |
FBIsWaitingEvent: should determine in a nonblocking manner, if there are messages or events to be processed. this is called in advance, prior to FBProcessEvent, which is called if messages/events to process really do exist. if there is no means to determine if events are there, simply return always true?
|
Well, that would be bad - it has to return false sometimes, as some processing is tied to "empty input queue" condition, e.g. painting or timer.
Quote: |
FBProcessEvent: here, *one single* backend message/event per call is dequeued and dispatched to upp understandable messages/events, using some custom translation mechanism..
|
Yep.
Quote: |
but there are more things one needs to implement:
bool GetShift() { uint8* ka = SDL_GetKeyState(NULL); return ka[SDLK_LSHIFT] || ka[SDLK_RSHIFT]; }
bool GetCtrl() { uint8* ka = SDL_GetKeyState(NULL); return ka[SDLK_LCTRL] || ka[SDLK_RCTRL]; }
bool GetAlt() { uint8* ka = SDL_GetKeyState(NULL); return ka[SDLK_LALT] || ka[SDLK_RALT]; }
bool GetCapsLock() { uint8* ka = SDL_GetKeyState(NULL); return ka[SDLK_CAPSLOCK]; }
bool GetMouseLeft() { return (SDL_GetMouseState(NULL,NULL) & SDL_BUTTON(SDL_BUTTON_LEFT)); }
bool GetMouseRight() { return (SDL_GetMouseState(NULL,NULL) & SDL_BUTTON(SDL_BUTTON_RIGHT)); }
bool GetMouseMiddle() { return (SDL_GetMouseState(NULL,NULL) & SDL_BUTTON(SDL_BUTTON_MIDDLE)); }
|
Careful here. The values MUST be frozen at the moment of input event. Same for GetMousePos.
Quote: |
the Keys.h assignments, for K_* of upp, caution, it uses some special structure, K_ALT and K_ALT_KEY are not the same..
|
Yep.
Mirek
[Updated on: Tue, 12 July 2011 18:58] Report message to a moderator
|
|
|
Re: Rainbow, first iteration [message #33177 is a reply to message #33169] |
Wed, 13 July 2011 10:46 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
now thats sort of preliminary doc thanks for clearifying this..
another big question in embedded systems is, after i have talked again with my boss, support for 565 (16Bit) drawn backend, means BufferPainter with 16 bit support. now this is quite important, since this is the second most case in ES. with theese 2, we'd probably habve 95 % cases.
we could blit accordingly in FBUpdate, but this would really have a performance hit.
what means do we have to do that?
EDIT:
i know you wrote:
message 9781
Quote: |
Well, our take (since the beginning) is that supporting other than 24 bit colors in the interface is not worth the trouble, especially supporting palettes is useless (the notable exception here is Image export/import infrastructure, where it is still required).
It was true in 1999 when we started and it is even more true now
That does not mean U++ apps would not work, they do, just look worse. U++ sets some default palette and uses it.
|
for ES this is not neccessarily well but i know, upp wasn't designed with ES in mind... so the question is, what to is the esiest path to have that? an own SystemDraw with a special BufferPainter?
[Updated on: Wed, 13 July 2011 11:20] Report message to a moderator
|
|
|
|
|
Re: Rainbow, first iteration [message #33198 is a reply to message #33177] |
Fri, 15 July 2011 15:13 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Wed, 13 July 2011 04:46 | now thats sort of preliminary doc thanks for clearifying this..
another big question in embedded systems is, after i have talked again with my boss, support for 565 (16Bit) drawn backend, means BufferPainter with 16 bit support. now this is quite important, since this is the second most case in ES. with theese 2, we'd probably habve 95 % cases.
we could blit accordingly in FBUpdate, but this would really have a performance hit.
what means do we have to do that?
EDIT:
i know you wrote:
message 9781
Quote: |
Well, our take (since the beginning) is that supporting other than 24 bit colors in the interface is not worth the trouble, especially supporting palettes is useless (the notable exception here is Image export/import infrastructure, where it is still required).
It was true in 1999 when we started and it is even more true now
That does not mean U++ apps would not work, they do, just look worse. U++ sets some default palette and uses it.
|
for ES this is not neccessarily well but i know, upp wasn't designed with ES in mind... so the question is, what to is the esiest path to have that? an own SystemDraw with a special BufferPainter?
|
I am afraid that even in this case, the best solution is still FBUpdate converting 24->16.
I believe that it should not be much really much slower.
That said, 16bit SystemDraw is still possible, but it is a big amount of work.
Mirek
|
|
|
|
Re: Rainbow, first iteration [message #33200 is a reply to message #33192] |
Fri, 15 July 2011 17:12 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Thu, 14 July 2011 09:09 | the current Ctrl::EndSession uses the Ctrl::fbEndSession, which is not evaluated anywhere..
is it supposed to be evaluated in FBEndSession?
|
Sorry, but I am yet not sure what is an overall correct behaviour w.r.t. system shutdown.
This thing was actually quite exposed by UWord with framebuffer, where it produces a lot of memory leaks on closing the host window (which is "system shutdown" for framebuffer).
I am considering add a new method, "Shutdown", to Ctrl interface. The behaviour in the case of system shutdown would then try to close all enabled TopWindows by:
- Calling Shutdown first
- If the window is not closed after Shutdown ends, "invoking close button". That should either close the window immediatelly, or invoke "Save? Yes No Cancel" sort of dialog (where "Cancel" does not make sense here, that is why there is the need for Shutdown).
- Repeat until there are any enabled windows that can be closed
- After that, leave all event loops (I mean all levels, so that we can properly exit thrugh leaving GUI_APP_MAIN)
|
|
|
|
|
Re: Rainbow, first iteration [message #33230 is a reply to message #33048] |
Tue, 19 July 2011 01:56 |
|
daveremba
Messages: 32 Registered: June 2011 Location: Los Angeles, CA, USA
|
Member |
|
|
For the MacOSX port, after looking at Rainbow,
I was thinking of using OpenGL for drawing,
and a small amount of Cocoa only for
window creation and events/input. I am not sure yet,
but you've already done the OpenGL work in Rainbow and
it ought to be portable. (so maybe much less need
for Cocoa code in Objective-C and mixed compiling
and linking)
Also, on SVN, what is uppsrc2, and uppdev?
Dave
[Updated on: Tue, 19 July 2011 02:09] Report message to a moderator
|
|
|
|
Re: Rainbow, first iteration [message #33236 is a reply to message #33230] |
Tue, 19 July 2011 10:33 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
daveremba wrote on Mon, 18 July 2011 19:56 | For the MacOSX port, after looking at Rainbow,
I was thinking of using OpenGL for drawing,
and a small amount of Cocoa only for
window creation and events/input. I am not sure yet,
but you've already done the OpenGL work in Rainbow and
it ought to be portable. (so maybe much less need
for Cocoa code in Objective-C and mixed compiling
and linking)
|
Not sure about OpenGL. I guess it should not be THAT hard to implement DrawText, DrawRect and DrawImage in Quartz2D...
Besides, the main problem is DrawText and font management - and there is no support for them in OpenGL.
Quote: |
Also, on SVN, what is uppsrc2, and uppdev?
|
uppsrc2 is a place where obsolete packages are moved.
uppdev is a place for "development packages", either tests or new packages being developed.
In short: you can ignore both
Mirek
|
|
|
|
Re: Rainbow, first iteration [message #33238 is a reply to message #33237] |
Tue, 19 July 2011 15:01 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
@unodogs: i am unable to find out what difference there is in PaintGl using WinGl and Paint using WinGl..the first compiles and runs, the latter compiles but crashes..
is there anything special about PaintGl? in theory, we should be able to enhance whichever application by more graphical backends. that's why i felt bold enough to try to use Paint with WinGl as well. any help here?
[Updated on: Tue, 19 July 2011 15:05] Report message to a moderator
|
|
|
Re: Rainbow, first iteration [message #33239 is a reply to message #33238] |
Tue, 19 July 2011 15:18 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
@mirek:
the EndSession for Framebuffer works quite well now. but there is a incoherency currently.
Win32Wnd.cpp(95):GLOBAL_VAR(bool, Ctrl::EndSession)
yields bool& Ctrl::EndSession();
which is not compliant to void Ctrl::EndSession() current behaviour.
this is used in Win32 and WinAlt, but X11 backend doesnt have it at all.
i'd suggest to have a usual bool Ctrl::endSession here, and move over to have a static void EndSession() as a public interface part. so this would become portable means.
EDIT: i commited in WinAlt the respective changes. maybe this whole EndSession thing can even go to CtrlCore, not to have to repeat the mess for each backend..
[Updated on: Tue, 19 July 2011 16:08] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Sun Jun 16 15:14:04 CEST 2024
Total time taken to generate the page: 0.02940 seconds
|