|
|
Home » Developing U++ » U++ Developers corner » let's discuss new Draw principles and problems...
|
Re: let's discuss new Draw principles and problems... [message #1003 is a reply to message #1002] |
Mon, 13 February 2006 13:35 |
jadeite
Messages: 42 Registered: January 2006
|
Member |
|
|
Firts, for those of us that are new, can you say -
- Is the 'new' Draw already implemented in current stable download, or is it only in uvs2/cvs?
- What is in the new Draw that is different from before?
What I would like:
- Fast, with anti-aliasing
- AGG support. Not necessarily as default, but optional. This is the way VCF does it. One line of code, and all of a sudden you are using AGG rendering for strokes and fills. It really is as simple as that. Nice for anti-aliasing, dashing, etc.
- Alpha blending/transparency in view area.
[Updated on: Mon, 13 February 2006 13:40] Report message to a moderator
|
|
|
Re: let's discuss new Draw principles and problems... [message #1004 is a reply to message #1002] |
Mon, 13 February 2006 13:41 |
|
mirek
Messages: 13980 Registered: November 2005
|
Ultimate Member |
|
|
Just to kickstart this discussion, I would like to list problems that I hope to solve:
- we need to enforce RGBA format as the dominant Image format. Current draw does not support alpha at any level. Host platforms support alpha images for raster bitmaps (starting with Win98).
- new Image will need new Icon designer.
- Text rendering should be redesigned, separating font information from Draw. Implementation should be improved to synthetise characters missing in Linux fonts.
Now of course comes evergreen question about advanced rendering capabilities. IMHO, this is two-headed problem:
- host platform support part - while Cairo and GDI+ are of course very nice, they fail to provide "runs out of box" guarantee
- meanwhile, dominant number of applications does not need advanced rendering at all
Makes me think there are two possibilities of advanced rendering (in fact, they are not mutually exclusive, so both can be sooner or later implemented):
- client-side advanced rendering, using direct access to the new RGBA surfaces. This has disadvantage of being quite a lot of work to do and not using hardware acceleration (OTOH, software can be pretty fast there as well). Advantage is that it would not require anything from the host platform, it would even allow using Draw on GUI-less machines (good for web servers). In fact, using some existing advanced rendering library here looks like quite a good option too (AGG comes to mind).
- using advanced rendering of host platform. That would involve having separate "DrawEx" package that would provide, for applications that need so, interface for host platform advanced rendering ops (GDI+, Cairo).
Mirek
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: let's discuss new Draw principles and problems... [message #1018 is a reply to message #1016] |
Tue, 14 February 2006 00:34 |
|
fudadmin
Messages: 1321 Registered: November 2005 Location: Kaunas, Lithuania
|
Ultimate Contributor Administrator |
|
|
luzr wrote on Mon, 13 February 2006 18:25 | How?
The only possibility is client-side draw (manipulating pixels in memory). Nice idea, but for some reason, some computers are too poor when transporting bitmaps from memory to VGA (as was shown by our tests - while other are perfectly OK to do so)
OTOH, as I have explained in the beginning, this is still one of options - but to do that, we need RGBA-dominant image. Working on it....
Mirek
|
What list of problems are exactly?
[Updated on: Tue, 14 February 2006 00:38] Report message to a moderator
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Thu May 16 19:02:16 CEST 2024
Total time taken to generate the page: 0.03384 seconds
|
|
|