Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Rainbow, first iteration  () 1 Vote
Re: Rainbow, first iteration [message #33081 is a reply to message #33053] Wed, 06 July 2011 09:44 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Tue, 05 July 2011 04:42

during debug of sdl backend i noticed a bug:

Win32Wnd.cpp:857
should have parenthesis around (ctr ? .. : ..)
have the same line in SDLFb, and it properly quits only with paranthesis. so quite sure the compiler does not recognize the meaning properly.
	while(!EndSession() && !quit && (ctrl ? ctrl->IsOpen() && ctrl->InLoop() : GetTopCtrls().GetCount()))


BTW
CtrlCore.h:1007
+	bool    IsIgnoreMouse() const                        { return ignoremouse; }


shouldn't
X11Proc.cpp:49 read this? similar to Win32Proc.. the K_ALT_KEY was missing

dword Ctrl::KEYtoK(dword key)
{
	if(key == K_ALT_KEY || key == K_CTRL_KEY || key == K_SHIFT_KEY)
		return key;
	if(GetCtrl()) key |= K_CTRL;
	if(GetAlt()) key |= K_ALT;
	if(GetShift()) key |= K_SHIFT;
	return key;
}




Applied.

Quote:


patch0 suggested PLATFORM_X11 changes for TDraw/util.cpp..
do you have other plans for them? i attach the this single patch again. i know of the PLATFORM_X11 legacy define..but uppsrc should be clean from it..uppsrc is not old legacy Smile

EDIT: btw: is there a reason why the UWord doesnt work with WinGl? (asuming addint the right packeges). it crashes..



TDraw is not canonical package. It is in the svn, but not in releaes. I will likely be moved to uppsrc2...

Mirek

Re: Rainbow, first iteration [message #33122 is a reply to message #33071] Fri, 08 July 2011 11:36 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
didn't want to open another thread for that:

const correctness for a virtual
PusherCtrl.h & Button.cpp
String Pusher::GetDesc() const;
Re: Rainbow, first iteration [message #33160 is a reply to message #33081] Tue, 12 July 2011 11:31 Go to previous messageGo to next message
kohait00 is currently offline  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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 Go to previous messageGo to next message
kohait00 is currently offline  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)
#define GUI_APP_MAIN \




[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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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).

Quote:


, BackDraw etc.)



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 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
now thats sort of preliminary doc Smile 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 Smile 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 #33188 is a reply to message #33177] Wed, 13 July 2011 17:48 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
LinuxFb: makes progress Smile i've got mouse events processing working. it has some SDL GPLed code, which i need to rewrite first, before i can commit it. keyboard processing is on the way, but that will be bit more dificult i think..
Re: Rainbow, first iteration [message #33192 is a reply to message #33188] Thu, 14 July 2011 15:09 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
the current Ctrl::EndSession uses the Ctrl::fbEndSession, which is not evaluated anywhere..

is it supposed to be evaluated in FBEndSession?
Re: Rainbow, first iteration [message #33198 is a reply to message #33177] Fri, 15 July 2011 15:13 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 13 July 2011 04:46

now thats sort of preliminary doc Smile 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 Smile 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 #33199 is a reply to message #33198] Fri, 15 July 2011 16:48 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
what would cover the work nesseccary?

Painter implementation for 16 bit??

FBEndSession & EndSession: any hints here?

BTW: is there a uniform way to gracuefully stop the application, besides calling the current TopWindow::Close? i mean sth like EndSession would be really great..to ensure the GUI_APP_MAIN can finish its work, which would not be using exit(0).. i need sth without a TopWindow instance as base...
Re: Rainbow, first iteration [message #33200 is a reply to message #33192] Fri, 15 July 2011 17:12 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 #33201 is a reply to message #33199] Fri, 15 July 2011 18:17 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Fri, 15 July 2011 10:48

what would cover the work nesseccary?

Painter implementation for 16 bit??



Yes, something like that.

Actually, now thinking about it, it would have to be that much hard. But I would rather try conversion at FBUpdate first anyway.

BTW, nice if not so much obvious trick during the conversion might be to test if the RGB source value is not the same as previous one (cache last value). Well, at least on CPU with branch prediction... I would say you would get 80% of "16-painter" performance this way.
Re: Rainbow, first iteration [message #33213 is a reply to message #33200] Sun, 17 July 2011 00:38 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
mirek wrote on Fri, 15 July 2011 08:12

Sorry, but I am yet not sure what is an overall correct behaviour w.r.t. system shutdown.


Here is something to consider for shutdown as I had problems with this in U++ (and Java).
http://www.ultimatepp.org/forum/index.php?t=msg&goto=300 02&#msg_30002

Shutting down each thread INSIDE the thread.

void endX(){end = true;	Sleep(2000);}	

GUI_APP_MAIN{
	GPSx2().Run();
	...
	...
	endX();

// and then in each thread
	    Sleep(1000);	
		while (CommPort.ReadDataWaiting() ) {
			if(end) break;
		  try{
// with global
void endX();
bool end;


So if "end=true;" the timing is such that each thread can shut itself down.

In Java it was handled with this one line:
af.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

Maybe something similar to this could be implemented in U++ as a way to shut down apps correctly.

Thread::ShutdownThreads(); Did not work for me!

Re: Rainbow, first iteration [message #33230 is a reply to message #33048] Tue, 19 July 2011 01:56 Go to previous messageGo to next message
daveremba is currently offline  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 #33235 is a reply to message #33230] Tue, 19 July 2011 09:17 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
sounds good. i don't mind to circumvent the macosx stuff as much as possible.. if we emulate the look and feel anyway and dont need the native means at all, that's more than perfect.


Re: Rainbow, first iteration [message #33236 is a reply to message #33230] Tue, 19 July 2011 10:33 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 Wink

Mirek
Re: Rainbow, first iteration [message #33237 is a reply to message #33236] Tue, 19 July 2011 10:42 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

mirek wrote on Tue, 19 July 2011 04:33


Besides, the main problem is DrawText and font management - and there is no support for them in OpenGL.


I'm trying to do something similar qt developers did ( http://labs.qt.nokia.com/2011/07/15/text-rendering-in-the-qm l-scene-graph) I have a working shader, but the main problem is distance field generator (I'm trying to port one from qt5)
Re: Rainbow, first iteration [message #33238 is a reply to message #33237] Tue, 19 July 2011 15:01 Go to previous messageGo to next message
kohait00 is currently offline  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 Go to previous messageGo to previous message
kohait00 is currently offline  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

Previous Topic: Upp Server (SVN, Redmine) down?
Next Topic: Docking package fixed and moved to uppsrc
Goto Forum:
  


Current Time: Thu Mar 28 09:39:50 CET 2024

Total time taken to generate the page: 0.02501 seconds