Home » U++ Library support » Look and Chameleon Technology » Chameleon, graphic technology
| Chameleon, graphic technology [message #2417] |
Wed, 12 April 2006 12:43  |
riri
Messages: 18
Registered: February 2006
Location: France
|
Promising Member |
|
|
Hi
I were trying to find any information about graphic improvement, like better integrated look & feel and so on on Ultimate++ (because I can't stand the pseudo WinXP L&F on GNU/Linux), and saw chameleon support in the roadmap. Not finding any revelant info with Google (seems this's a third party techno ?), so I tried to find the info in upp forums, but unsuccesfully.
I understood that this chameleon techno will be the solution for look (and even skins) in the future, but what about this techno ? do you have any information about it ? Is the developement started (in this's not a third party solution) ? when do you plan the Big Jump ?
Thanks in advance
|
|
|
|
| Re: Chameleon, graphic technology [message #2421 is a reply to message #2417] |
Wed, 12 April 2006 13:28  |
 |
mirek
Messages: 14255
Registered: November 2005
|
Ultimate Member |
|
|
| riri wrote on Wed, 12 April 2006 06:43 |
Hi
I were trying to find any information about graphic improvement, like better integrated look & feel and so on on Ultimate++ (because I can't stand the pseudo WinXP L&F on GNU/Linux), and saw chameleon support in the roadmap. Not finding any revelant info with Google (seems this's a third party techno ?), so I tried to find the info in upp forums, but unsuccesfully.
I understood that this chameleon techno will be the solution for look (and even skins) in the future, but what about this techno ? do you have any information about it ? Is the developement started (in this's not a third party solution) ? when do you plan the Big Jump ?
Thanks in advance
|
Well, right now we are in process of refactoring "rendering infrastructure". This is mostly about raster image processing capabilities, which took more time to do than anticipated, OTOH gives unexpectly nice framework for manipulating images. (One of nice features is that the same code can be used to e.g. sharpen in memory icon Image and sharpen 10GB raster file, without any performance compromises on either side).
When that is done, we will most likely have to write new Image designer (with alpha support) and then will be time for Chameleon.
Mirek
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Chameleon, graphic technology [message #2440 is a reply to message #2431] |
Wed, 12 April 2006 18:18 |
|
|
|
We could also add cairo as a render engine in linux, because now it uses opengl to paint everything (if xgl is run)... (we could be faster than trolltech which plans to use opengl since 4.1 version of qt)
|
|
|
|
| Re: Chameleon, graphic technology [message #2441 is a reply to message #2440] |
Wed, 12 April 2006 18:40 |
|
mirek
Messages: 14255
Registered: November 2005
|
Ultimate Member |
|
|
Well, I disagree. After one year of searching, I think that the basic drawing model should be left as it is.
There are too many rendering options now and it will be better to leave them as extensions. Adding cairo (or AGG or GDI+ or QuickDraw) as the only model would IMO have serious impact on portability and performance.
To my knowledge, far not everything is accelerated in cairo. In the end, cairo is 2D memory surface painter for many ops, just like AGG etc... In fact, using OpenGL might work as nice decceleration in many cases (because you are forced to swap memory surfaces there and back all the time).
That said, my current intentions are like this:
Current Draw model being left just where it is. Then add "extensions", like cairo. In the code it should look like this:
void MyCtrl::Paint(Draw& w)
{
Cairo cairo(w);
cairo.DoStuff()....
}
Another reason is the printing problem. I have not checked that completely, but I am afraid then when you are going to print Cairo or AGG produced output, it simply gets rendered as large bitmaps -> slow. My customers would not be pleased when waiting for large reports.
Another things to consider, quite similar, is terminal access and X11 over the NET...
By using "extended" model for parts where it is really needed only, we can (I hope) have best of all worlds...
Mirek
|
|
|
|
| Re: Chameleon, graphic technology [message #2442 is a reply to message #2441] |
Wed, 12 April 2006 19:12 |
|
|
| luzr wrote on Wed, 12 April 2006 12:40 |
Well, I disagree. After one year of searching, I think that the basic drawing model should be left as it is.
There are too many rendering options now and it will be better to leave them as extensions. Adding cairo (or AGG or GDI+ or QuickDraw) as the only model would IMO have serious impact on portability and performance.
To my knowledge, far not everything is accelerated in cairo. In the end, cairo is 2D memory surface painter for many ops, just like AGG etc... In fact, using OpenGL might work as nice decceleration in many cases (because you are forced to swap memory surfaces there and back all the time).
That said, my current intentions are like this:
Current Draw model being left just where it is. Then add "extensions", like cairo. In the code it should look like this:
void MyCtrl::Paint(Draw& w)
{
Cairo cairo(w);
cairo.DoStuff()....
}
Another reason is the printing problem. I have not checked that completely, but I am afraid then when you are going to print Cairo or AGG produced output, it simply gets rendered as large bitmaps -> slow. My customers would not be pleased when waiting for large reports.
Another things to consider, quite similar, is terminal access and X11 over the NET...
By using "extended" model for parts where it is really needed only, we can (I hope) have best of all worlds...
Mirek
|
I didn't make myself clear. I wanted cairo to be "under Draw" just like gdi or xlib is now. Just as a next rendering engine (used automaticaly if opengled env is detected). Of course if there is a better lib that use opengl we should go for it. I mentioned cairo because this is the only lib using opengl I know (and which really works (newest gtk use it)).
|
|
|
|
| Re: Chameleon, graphic technology [message #2443 is a reply to message #2441] |
Wed, 12 April 2006 19:54 |
 |
fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
|
Ultimate Contributor
Administrator |
|
|
| luzr wrote on Wed, 12 April 2006 17:40 |
Well, I disagree. After one year of searching, I think that the basic drawing model should be left as it is.
There are too many rendering options now and it will be better to leave them as extensions. Adding cairo (or AGG or GDI+ or QuickDraw) as the only model would IMO have serious impact on portability and performance.
To my knowledge, far not everything is accelerated in cairo. In the end, cairo is 2D memory surface painter for many ops, just like AGG etc... In fact, using OpenGL might work as nice decceleration in many cases (because you are forced to swap memory surfaces there and back all the time).
That said, my current intentions are like this:
Current Draw model being left just where it is. Then add "extensions", like cairo. In the code it should look like this:
void MyCtrl::Paint(Draw& w)
{
Cairo cairo(w);
cairo.DoStuff()....
}
Another reason is the printing problem. I have not checked that completely, but I am afraid then when you are going to print Cairo or AGG produced output, it simply gets rendered as large bitmaps -> slow. My customers would not be pleased when waiting for large reports.
Another things to consider, quite similar, is terminal access and X11 over the NET...
By using "extended" model for parts where it is really needed only, we can (I hope) have best of all worlds...
Mirek
|
Yes. I agree with your approach. Even more after I studied Ultimate's Draw. Very nice...!
|
|
|
|
| Re: Chameleon, graphic technology [message #2444 is a reply to message #2443] |
Wed, 12 April 2006 21:00 |
|
mirek
Messages: 14255
Registered: November 2005
|
Ultimate Member |
|
|
| fudadmin wrote on Wed, 12 April 2006 13:54 |
Yes. I agree with your approach. Even more after I studied Ultimate's Draw. Very nice...!
|
Speaking about it, I would like to ask you to start investigating how U++ encapsulation of AGG should look like....
There are some things to consider:
"Draw extensions", as described above, should work with most likely two targets: raw memory surfaces and Drawing.
How interfaces to achieve this will work is much to be decided, however, memory surfaces will be used for screen rendering and also for printing, which should be in general achieved (just like it is now in most cases) by using Drawing interface first, and then some sort of optimalized banding technique - real implementation will depend, but I think that Drawing as intermediate storage media for printing will be very helpful.
I believe that current basic design principle of mostly stateless Draw is sound - at least for kind of applications we usually develop, so please take that into consideration (means, it would be nice to reproduce this on another level with advanced rendering).
Mirek
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 25 19:01:22 CEST 2025
Total time taken to generate the page: 0.00681 seconds
|
Members
Pages
Help
Register
Login
Home
