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 #33241 is a reply to message #33239] Tue, 19 July 2011 21:29 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Tue, 19 July 2011 09:18

@mirek:

the EndSession for Framebuffer works quite well now. but there is a incoherency currently.



Yes, I know, RM #86...

Mirek

[Updated on: Tue, 19 July 2011 21:29]

Report message to a moderator

Re: Rainbow, first iteration [message #33242 is a reply to message #33238] Tue, 19 July 2011 22:28 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

kohait00 wrote on Tue, 19 July 2011 09:01

@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?


PaintGl was simply a test application for WinGl backend. I will remove it soon. Could you pull the latest sources and tell me if it still crashes (and where)? I cannot reproduce it..

Ok I know what is your problem. Please copy tahoma.fnt and tahoma.png files from PaintGl to Paint folder.. (later basic fonts will be automatically linked or generated on the fly)

[Updated on: Tue, 19 July 2011 22:31]

Report message to a moderator

Re: Rainbow, first iteration [message #33245 is a reply to message #33236] Wed, 20 July 2011 06:17 Go to previous messageGo to next message
daveremba is currently offline  daveremba
Messages: 32
Registered: June 2011
Location: Los Angeles, CA, USA
Member
Are there more font capabilities needed beyond
the choices in the layout editor?

index.php?t=getfile&id=3387&private=0

Quote:

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.



There are some font support libraries for OpenGL:
basic support in GLUT, some newer libraries for the
gamers, and an older one for FreeType:
http://oglft.sourceforge.net/

--

I'm continuing to look also at Qt, wx, and Firefox.
They solve the problem of late-binding in Objective-C
and avoid the NIB file (static layout).

If anyone is curious, here is a link to an Apple man page explaining Cocoa
as it relates to the OS architecure.

As far as mixing Cocoa and C++ that is certainly do-able,
even from UPP theide by adding some options to gcc:

gcc main.m cocoa_test1AppDelegate.m -framework Foundation -framework Cocoa -o test

Cocoa apps also want to be wrapped in a folder called a
"bundle" with an info.plist XML file that defines it to
be an "app" to MacOSX. Xcode makes one when apps are built,
and bundle could also be built as a post-processing step in theide.

--

Lastly, what is chameleon? Theme-related? For example,
how does one change the background or default color of controls
in the layout?

Dave


[Updated on: Wed, 20 July 2011 06:33]

Report message to a moderator

Re: Rainbow, first iteration [message #33246 is a reply to message #33245] Wed, 20 July 2011 07:13 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
daveremba wrote on Wed, 20 July 2011 00:17

Are there more font capabilities needed beyond
the choices in the layout editor?

index.php?t=getfile&id=3387&private=0



Yes.

Check Font class in Draw.

We need the complete metrics of glyphs, capability of render unicode, the list of all fonts, and to identify 3 basic fonts (serif, sans-serif, monospace).

Quote:


I'm continuing to look also at Qt, wx, and Firefox.
They solve the problem of late-binding in Objective-C
and avoid the NIB file (static layout).



Excelent.

Quote:


gcc main.m cocoa_test1AppDelegate.m -framework Foundation -framework Cocoa -o test




I suspect that "-framework" is link step option, correct?

Quote:


Cocoa apps also want to be wrapped in a folder called a
"bundle" with an info.plist XML file that defines it to
be an "app" to MacOSX. Xcode makes one when apps are built,
and bundle could also be built as a post-processing step in theide.



My bet is there will be some commandline way to make the bundle. Plus we will have to get theide to generate the .xml (perhaps replacing only the name of application).

Quote:



Lastly, what is chameleon? Theme-related? For example,
how does one change the background or default color of controls
in the layout?




Yes, it is skinning system. It is not so much about skinning individial widgets, but the whole GUI.

There is simple example covering basics:

http://www.ultimatepp.org/reference$Chameleon$en-us.html

(well, in this case, individual widgets are skinned, but that is not the common use).

Mirek
Re: Rainbow, first iteration [message #33248 is a reply to message #33242] Wed, 20 July 2011 10:28 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
@unodogs:
Quote:


copy tahoma.fnt and tahoma.png files from PaintGl to Paint


that was the missing part, how could i be that blind. expected sth. in code.. runs like a charm

is it possible to move the fonts somehow in WinGl to relief the user from that?
Re: Rainbow, first iteration [message #33249 is a reply to message #33248] Wed, 20 July 2011 10:48 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

kohait00 wrote on Wed, 20 July 2011 04:28

@unodogs:
Quote:


copy tahoma.fnt and tahoma.png files from PaintGl to Paint


is it possible to move the fonts somehow in WinGl to relief the user from that?

First I wanted to embed fonts in WinGl package using brc files. Unfortunately brc files cannot be properly linked in 64b mode. So for now I'll just use iml file to store font's texture and String variable to store font definition. I don't like it (it hard to replace and edit) but I don't see other solution right now. Like I said in one of my previous posts I want to use qt's technique to generate font definition on the fly, but I need some time to do that.
Re: Rainbow, first iteration [message #33253 is a reply to message #33249] Wed, 20 July 2011 15:43 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
LinuxFb works now in most parts. one thing still to manage is the view draw optimization..any idea on what could help here?

EDIT: there are some drawing problems with widgets that i can remember to already have seen..is it an issue with static controls initialized before the GUI?? no idea how to fix that..
index.php?t=getfile&id=3388&private=0

[Updated on: Wed, 20 July 2011 15:56]

Report message to a moderator

Re: Rainbow, first iteration [message #33255 is a reply to message #33253] Wed, 20 July 2011 17:04 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 20 July 2011 09:43

LinuxFb works now in most parts. one thing still to manage is the view draw optimization..any idea on what could help here?



What exactly is the problem?

Quote:


EDIT: there are some drawing problems with widgets that i can remember to already have seen..is it an issue with static controls initialized before the GUI?? no idea how to fix that..



It looks like metrics problem, most likely font metrics issue. Try DDUMP(GetStdFontCy()) (should be something between 10 - 20).

Other than that, congratulations. I guess we are heading in the right direction.

I plan to mostly finish framebuffer this weekend.

Re: Rainbow, first iteration [message #33260 is a reply to message #33255] Thu, 21 July 2011 00:10 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
Thanks. Thema Problem With FBUpdate rect...IT curently copies Thema entire framebuffer...which slooooooows down. Same thing Tor sdlfb.

I will Check font metrics.thanks for the hint.
Re: Rainbow, first iteration [message #33261 is a reply to message #33246] Thu, 21 July 2011 00:37 Go to previous messageGo to next message
daveremba is currently offline  daveremba
Messages: 32
Registered: June 2011
Location: Los Angeles, CA, USA
Member
gcc main.m cocoa_test1AppDelegate.m -framework Foundation -framework Cocoa -o test
mirek wrote on Tue, 19 July 2011 22:13


I suspect that "-framework" is link step option, correct
Yes:
-framework name[,suffix]
"This option tells the linker to search for `name.framework/name' the framework search path."
...
The default framework search path is /Library/Frameworks then /System/Library/Frameworks
An UPP installation for all users (treating UPP as any MacOSX product/application) can put its libraries there.
mirek wrote on Tue, 19 July 2011 22:13

My bet is there will be some commandline way to make the bundle. Plus we will have to get theide to generate the .xml (perhaps replacing only the name of application).
It isn't too complex and there is documentation.
I made a bundle of the X11 version of theide, it works
the same except that a terminal shell window is not
created (same as a "subsystem: windows" app).
--
mirek wrote on Tue, 19 July 2011 22:13

We need the complete metrics of glyphs, capability of render unicode, the list of all fonts, and to identify 3 basic fonts (serif, sans-serif, monospace).
about "render unicode" ...

I didn't see UTF-16/unicode support in UPP. Is that
something planned to be added?

Dave

[Updated on: Thu, 21 July 2011 01:45]

Report message to a moderator

Re: Rainbow, first iteration [message #33264 is a reply to message #33261] Thu, 21 July 2011 11:28 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
daveremba wrote on Wed, 20 July 2011 18:37


I didn't see UTF-16/unicode support in UPP. Is that
something planned to be added?

Dave



Well, perhaps it is because U++ is completely UTF-16 based? Smile

For compatibility reason, you can set 8-bit encoding on app-wide basis, but recommended default there is UTF-8.

In any case, all fontmetrics info is UTF-16 and the basic Draw::DrawTextOp method expects UTF-16...
Re: Rainbow, first iteration [message #33265 is a reply to message #33255] Thu, 21 July 2011 12:08 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
mirek wrote on Wed, 20 July 2011 17:04


It looks like metrics problem, most likely font metrics issue. Try DDUMP(GetStdFontCy()) (should be something between 10 - 20).


you were right.. it reports 0.
where does the font stuff get initialized or how to fix it?

cheers
Re: Rainbow, first iteration [message #33266 is a reply to message #33265] Thu, 21 July 2011 12:14 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
void Font::InitStdFont()

Related files are Draw/Font.cpp, FontFc.cpp (for fontconfig/freetype).

Note: I am afraid that for the full Mac implementation, we will need "FontQuartz.cpp". But I guess fontconfig/freetype can be temporalily replacements there...
Re: Rainbow, first iteration [message #33268 is a reply to message #33266] Thu, 21 July 2011 16:16 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
it worked out fine with
	Font::SetStdFont(ScreenSans(12));


but is there any possibility to have the font handling completely seperated as per backend basis? there is still code mixed in Draw/Font.cpp and so on..
Re: Rainbow, first iteration [message #33269 is a reply to message #33268] Thu, 21 July 2011 18:40 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Thu, 21 July 2011 10:16

it worked out fine with
	Font::SetStdFont(ScreenSans(12));


but is there any possibility to have the font handling completely seperated as per backend basis? there is still code mixed in Draw/Font.cpp and so on..



Well, I am considering it, but:

a) there are only 3 possible font metrics system we have to support
b) the code is relatively small without too many caveats (unlike GUI backend).

So I guess it is now worth it....
Re: Rainbow, first iteration [message #33270 is a reply to message #33268] Thu, 21 July 2011 18:43 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Thu, 21 July 2011 10:16

it worked out fine with
	Font::SetStdFont(ScreenSans(12));





..I guess this call should be placed somewhere in either Framebuffer or ChStd..
Re: Rainbow, first iteration [message #33271 is a reply to message #33270] Thu, 21 July 2011 18:48 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
not neccessarily..
Font.cpp
InitStdFont() needs a restructuring, because, currently, win fonts are know, and can SyncStdFont, while i.e. X11 also does the
Font::SetStdFont(ScreenSans(12)); trick but later in init, which calls SyncStdFont as well. so it's kinda messy..

so best thing is to make InitStdFont or sth also backend dependant..

[Updated on: Thu, 21 July 2011 18:49]

Report message to a moderator

Re: Rainbow, first iteration [message #33279 is a reply to message #33271] Fri, 22 July 2011 11:42 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
@mirek:
Quote:


So I guess it is now worth it....


... to change behavior or to leave it as is Smile ?

meanwhile i will move the correspinding thing to InitFB..depending on POSIX...since WIN32 does init it..
Re: Rainbow, first iteration [message #33280 is a reply to message #33279] Fri, 22 July 2011 13:23 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
I was wondering what are required steps to get a new Rainbow backend started. Nothing too complicated, only something that can render the contents of a TopWindow (no border/sizing required) with a Paint method. I do not need fonts, Painter or other more advanced features.

Can you give me any instructions/hint/first steps? Do I need the rainbow from trunk or branches. I am guessing the skeleton package is a striped down starting point.

I want to try to investigate during weekend if my Irrlicht windowing system can be converted to a Rainbow backend.
Re: Rainbow, first iteration [message #33282 is a reply to message #33280] Fri, 22 July 2011 14:17 Go to previous messageGo to previous message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
@mirek:

I am experimenting with a ImageBuffer hack (including Buffer<>) to pass the fb surface directly as underlaying for Ctrl::framebuffer. the speed improvements for win/linux, fb0/SDL are considerable. especially in terms of responsiveness of the input handling.
while video handling under pc systems wont see much advantage, direct handling in embedded will really profit.

maybe we should really think about making upp directly drawable on fb surface, and making double buffering optional..

i will provide a patch to test it for your self. it is really quick.

@cbpporter: consider using WinAlt, in comparison with Skeleton, to see what exactly is needed. framebuffer is really a good choice as well, if irrlicht can offer a direct surface to draw to..fb based would not profit from optimized draw operations of irrlich though. see progress of MacOS port..it's getting exciting Smile imagine upp running on all the backends..this is a huge advantage.

EDIT: the attached patch is a quick hack to enable the usage of a n arbitrary memory chunk under ImageBuffer. Buffer<> is extended with a ctor and ability to hold not owned memory. ImageBuffer is extended to be constructable from a supplied Buffer<RGBA> plus Size, Ctrl::framebuffer is made public, so it's Buffer can be replaced.

while Linux/SDL somewhat does not show improvements, win/SDL are really responsive. LinuxFb heavily profits from the speed. again, my vote is for making this possible, so upp can run on at least some embeddeds (we would love to use it in our company in such way)

[Updated on: Fri, 22 July 2011 15:48]

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 22:49:19 CET 2024

Total time taken to generate the page: 0.01627 seconds