[Cdk-devel] [ cdk-Bugs-889829 ] Transparent Renderer2D implementation proposal

[SourceForge.net <no...@so...>]

Bugs item #889829, was opened at 2004-02-03 16:46
Message generated for change (Comment added) made by akrassavine
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120024&aid=889829&group_id=20024

Category: org.openscience.cdk.renderer
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anatoli Krassavine (akrassavine)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transparent Renderer2D implementation proposal

Initial Comment:
I propose to provide a specialist implementation of 
Render2D for rendering transparent 2D structures (my 
working version is attached). The principal different 
from existing Render2D is that this implementation 
manipulates the clipping area to control painting of 
empty space under atomic symbols instead of filling it 
with background color. 

Rationale:

To understand why this might be important one needs 
to take a look at how Renderer2D presently draws 
structures.

1)	draw all bonds from the centres of respective 
atoms
2)	fill in the rectangles over which atomic 
symbols will be drawn with the background color
3)	draw  the atomic symbols

Note that we draw more of the bonds then we actually 
need. Later we simply erase it with background color. 
As far as this is done on the screen, it is not a problem. 
The problems arise when one tries to superimpose 
renderer on a non-flat background or convert it into a 
vector or raster graphics directly (think SVG). It would 
be very nice to have SVG impression of a molecule 
which could be renderered with any background color.

In this case the background rectangles prevent code 
from generating a proper transparent impression. It 
specifically means that Renderer2d should always 
completely fill its background with background color, 
which it needs to know in advance. It is especially hard 
when the workflow does not provide the code with the 
opportunity to know the background color in advance.

Of course one could implement all sorts of workarounds 
(such as painting a memory image and then marking a 
background color as transparent in color model and 
then exporting it – nevertheless it is pretty problematic 
and requires code to go through an extra image 
processing stage.

Implementation:

The new painting algorithm was implemented to ensure 
minimum impact on existing code

1) Create a mask for future clipping – initially it 
encompasses the whole of painting area
2) Draw all atomic symbols first. Whenever we need to 
clear empty space, simply subtract the rectangle from 
the mask
3) Set the current clipping area to the mask
4) Draw the bonds as normal – they will be clipped as 
they are drawn. 

Note that I moved the RingSet generation functionality 
into a separate protected method – this makes the code 
cleaner and perhaps should be moved into original 
Renderer2D codebase.

The code could be further clarified if 
getScreenSize() and getScreenCoordinates() methods 
in Render2D are make protected (as they should) – I 
placed it in as another bug.


Considerations:

Surprisingly, the performance of modified code is 
actually slightly better then the original (according to 
my benchmarks). This is because the clipping area 
analysis for few atomic symbols is a relatively cheap 
operation in Graphics2D compared to filling the pixels 
with the color. Nevertheless, I am not sure if it is a 
good idea to replace original Renderer2D 
implementation with a new one. I am more comfortable 
to keep it as a specialist extension.


----------------------------------------------------------------------

>Comment By: Anatoli Krassavine (akrassavine)
Date: 2004-02-04 14:57

Message:
Logged In: YES 
user_id=552055

There are no specific issues with replacing current 
Renderer2D implementation. I guess that my caution was 
due to general paranoya more then anything else, :-). On the 
other hand, with 20040202 released, it is a perfect time to 
do such a change.

The things to look for:
1) possible performance impact should be carefully analized
2) the code should be modified to get the initial mask 
bounds from r2dm.getBackgroundDimension() and not have 
them hard-coded
3) double-check that no code explicitly relies on using 
background fill (I do not believe any does).

I have reattached a version which handles dimensions 
correctly.

----------------------------------------------------------------------

Comment By: Egon Willighagen (egonw)
Date: 2004-02-04 14:23

Message:
Logged In: YES 
user_id=25678

This might be a very nice improvement of the current code. 
I like your suggestion. I'm about to apply the changes you 
filed in the other bug report. 
 
What makes you hesitative about applying the chanes to the 
original Renderer2D ? 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120024&aid=889829&group_id=20024