U++ framework: U++ Developers corner » let's discuss new Draw principles and problems...

Home » Developing U++ » U++ Developers corner » let's discuss new Draw principles and problems...

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

let's discuss new Draw principles and problems... [message #1002]

Mon, 13 February 2006 13:22

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

I'd like our cozy community to express their opinions about the features of the new Draw. Maybe that would help to make it really cool? What do think? What do you expect from it? What are the current problems?

Report message to a moderator

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: 14290
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

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1005 is a reply to message #1002]

Mon, 13 February 2006 14:30

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

1. I'd like to have choices (like global settings) to use hardware acceleration or not etc.
2. Also, as many choices for configuration as possible.
3. Maybe intelligent (statistical?) self-reconfiguration.
4. What if to program some parts of it in pure assembler?

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1006 is a reply to message #1002]

Mon, 13 February 2006 14:46

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

BTW, pixel manipulations can be done in memory but IMOH the bottleneck is to pump them from RAM memory to video card memory. Especially, in 32bit format. What tricks do you propose?

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1007 is a reply to message #1006]

Mon, 13 February 2006 16:12

mirek
Messages: 14290
Registered: November 2005

Ultimate Member

BTW, as tests clearly showed, for very complex scenes (like full screen of letters, each letter has different color), overhead associated with pumping graphical commands through OS to videocard is quite high too... (even higher than pumping single bitmap)

So it all depends. That is why Draw is quite consrvative in what to expect from hardware/OS and I would like to keep it that way.

Mirek

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1010 is a reply to message #1002]

Mon, 13 February 2006 23:49

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

Is semi-transparent menus considered advanced graphics?

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1011 is a reply to message #1010]

Tue, 14 February 2006 00:04

mirek
Messages: 14290
Registered: November 2005

Ultimate Member

No. Everything at "whole-window" level is already possible.

In fact, U++ already uses transparency (blending) for menu visual effects.

I have already experimented with semitransparent menus, it is no problem aside form the fact that it is not standard appearance in WinXP.

Mirek

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1012 is a reply to message #1002]

Tue, 14 February 2006 00:05

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

what if to use regions with less bits as possible and an array of changing palettes (kind of compression and styles) and multi-buffering?

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1013 is a reply to message #1011]

Tue, 14 February 2006 00:09

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

luzr wrote on Mon, 13 February 2006 18:04

... it is not standard appearance in WinXP.

Mirek

But Windows Vista is comming... (BTW, very vector oriented...)

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1014 is a reply to message #1013]

Tue, 14 February 2006 00:17

mirek
Messages: 14290
Registered: November 2005

Ultimate Member

Then we have to hope we will better have "chameleon" ready by the time Vista comes Smile

Well, you know, in fact this "advanced draw" pressure makes me uneasy. The real problem is that it would be very easy to use GDI+ and allow all kinds of visual eye-candy. However, it would at the same time mean bye bye to Linux/Win2k/Win98 compatibility, very likely also bye byte to printing, to export PDFs etc, etc...

Mirek

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1015 is a reply to message #1002]

Tue, 14 February 2006 00:22

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

what if to make our own "GDI+" for all OS?

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1016 is a reply to message #1015]

Tue, 14 February 2006 00:25

mirek
Messages: 14290
Registered: November 2005

Ultimate Member

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

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1017 is a reply to message #1015]

Tue, 14 February 2006 00:30

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

fudadmin wrote on Mon, 13 February 2006 18:22

what if to make our own "GDI+" for all OS?

BTW, at the moment I'm experimenting with assembler... Also, maybe we can find some ready-to-use functions on the net?

Report message to a moderator

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

What list of problems are exactly?

[Updated on: Tue, 14 February 2006 00:38]

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1019 is a reply to message #1017]

Tue, 14 February 2006 01:09

mirek
Messages: 14290
Registered: November 2005

Ultimate Member

Well, assembler is not a problem, but not a huge win either. You know, in initial experiments, the problem was not to render the image by software, but to put it to screen (pump it though the OS). Assembler is not gone help there.

Just interesting sidenote: Hand-made assembly did not gave us any significant improvements over C++ code, 10% was maximum I was able to achieve. Seems like modern CPUs and compilers are quiete optimal when dealing with C++ code...

Mirek

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1020 is a reply to message #1019]

Tue, 14 February 2006 09:26

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

What if to use TV principle: use even and odd scanlines?

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1021 is a reply to message #1020]

Tue, 14 February 2006 09:35

mirek
Messages: 14290
Registered: November 2005

Ultimate Member

To reduce required bandwith?

Well, interesting idea, but I doubt visual artifacts would be acceptable.

Frankly, what is bad about this:

- use basic Draw for most parts that do not require advanced rendering (e.g. editor in TheIDE)

- use client-side, double-buffered extended Draw (perhaps AGG based) for intensive graphical tasks

?

Mirek

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1022 is a reply to message #1021]

Tue, 14 February 2006 10:59

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

luzr wrote on Tue, 14 February 2006 03:35

To reduce required bandwith?

to fool the eye and speed up.

Quote:

Well, interesting idea, but I doubt visual artifacts would be acceptable.

what exactly? I think opposite! It would give nice and smooth rendering. Solar OS use it as main one. And I guess even more applications... I suspect even Opera's menus ...

Quote:

Frankly, what is bad about this:

- use basic Draw for most parts that do not require advanced rendering (e.g. editor in TheIDE)

Why then do we need the new draw at all? Or let's make separate modules? Maybe we need a structured list with all the requirements?

Quote:

- use client-side, double-buffered extended Draw (perhaps AGG based) for intensive graphical tasks

I expect multi-buffered with "dirty" rectangles and/or regions...

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1023 is a reply to message #1022]

Tue, 14 February 2006 11:17

mirek
Messages: 14290
Registered: November 2005

Ultimate Member

Interlaced:

E.g. imagine holding page-down (with 30 fps autorepeat) in wordprocessor and interlaced rendering - you would see two pages at once.

Why new Draw:

New Draw infrastructure is needed to allow client-side advanced drawing. We just need to take this first step to get any further. How advanced draw will look like does not depend on this first step. Second reason is that current Draw raster image model does not support RGBA images and that is a serious flaw.

Mirek

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1024 is a reply to message #1023]

Tue, 14 February 2006 11:54

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

Let's talk RGBA problem.
What do we need for RGBA exactly? Can we split this RGBA problem into 2 parts:
1 Part. Load, save, convert - format problems and manipulations in memory. (We need functions for them). What else?

2 Part. Display - "pumping" problems? But, AFAIK, 4 bytes is even better than 3 bytes for pumping. And let's say we can forget about hardware acceleration because as your tests show and materials on the net - there's no real advantage of it for 2D.What else?

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1025 is a reply to message #1024]

Tue, 14 February 2006 12:12

mirek
Messages: 14290
Registered: November 2005

Ultimate Member

- We need RGBA because we need RGBA images. RGBA is simply the most generic format (well, theoretically we could also think about 8 bytes RGBA - 2 bytes per channel).

- From pumping perspective, on modern GPU (by modern I mean anything past 1998) the source format does not matter, as conversions are performed by GPU. However, it makes _huge_ difference for sofware rendering operations. What is even more important, you have to implement rendering just for single format.

- It is true that for rendering itself, HW acceleration does not matter. However, pumping to video memory can be bottleneck for many machines.

Actually, the original idea (valid for last year's plans) was exactly that - do everything in sofware. That was before you have run the tests on your machine, showing amazing 10fps pumping performance (worst case since that was 40fps on unodgs Duron and even that was barely acceptable, many machines are capable of 200+ fps on that test).

Another possible disadvantage of software rendering is that you cannot use it for printer (it would be too slow).

Yet another disadvantage is that software rendering places high(er) load on CPU (means higher overal power consumption - bad for laptops).

I believe that what we are working on now will provide reasonable compromise (default normal rendering, advanced software rendering where needed).

Mirek

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1047 is a reply to message #1002]

Thu, 16 February 2006 08:22

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

What do you think of CxImage library? Could we use it all or some parts of it? It has free zlib licence.
http://www.codeproject.com/bitmap/cximage.asp

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1049 is a reply to message #1047]

Thu, 16 February 2006 13:43

jadeite
Messages: 42
Registered: January 2006

Member

fudadmin wrote on Thu, 16 February 2006 02:22

What do you think of CxImage library?

I don't know anything about this lib except from what I read in the 1st paragragraph of the codeproject article. Although the 'core' of the lib might be platform independent, the author clearly claims that the lib as a whole is not. The question is, can the platform dependent part be factored out easily by the devs here? If not, is this really the road you plan to take, locking yourself into Windows?

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1050 is a reply to message #1047]

Thu, 16 February 2006 15:01

fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania

Ultimate Contributor
Administrator

I've downloaded the sources of CxImage and AGG. AGG is definetely more useful. And it's more elegant in terms of programming style. IMHO, Myrek should find a niche for AGG in U++...

Report message to a moderator

Re: let's discuss new Draw principles and problems... [message #1051 is a reply to message #1050]

Thu, 16 February 2006 17:15

mirek
Messages: 14290
Registered: November 2005

Ultimate Member

I already did.

Whith new ARGB Image with direct surface access, you will be able to plugin similar libraries without too much hassle.

AGG is definitely the most interesting candidate.

Mirek

Report message to a moderator

Xara Xtreme Engine [message #3614 is a reply to message #1002]

Wed, 07 June 2006 10:59

CyberEye
Messages: 4
Registered: June 2006
Location: Germany

Junior Member

Hello @ all!

This is my first posting here and I must say: Ultimate++ and TheIDE are very good! The concept is awesome! One little critic: The Ultimate++ Framework is this time less documented. But I know, that this task is work in progress. Wink

But now to the topic:
I have read, that there is a problem to find a good platformindependent Draw-Engine.

What do you think about "Xara Xtreme"?
http://www.xaraxtreme.org

It is Open-Source for Linux. But I think, you can adept the engine and use it for platformindependent implementation.

Or do you search an Engine, to draw the GUI itself? Such as GTK, GDI, ...?

friendly greetings

CyberEye

PS.: I'm from Germany, so do not critic my English much, please. Rolling Eyes