U++ forum: Welcome to the forum

Search on this site

Search in forums

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

Show: Today's Messages :: Show 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: 13976
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: 13976
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: 13976
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: 13976
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: 13976
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: 13976
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: 13976
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: 13976
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

Pages (2): [1 2 › »]

Previous Topic:	Task: WinCE build environment
Next Topic:	Should we double-buffer by default?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat May 11 20:33:13 CEST 2024

Total time taken to generate the page: 0.03748 seconds