Using fully transparent background color causes display glitch

Question

Version 3.11.1 / Java 1.7.0_45 (HotSpot VM) / Windows 7

Using a transparent background color exposes a GUI bug that corrupts the background of the editor's display area. Graph elements are drawn correctly, but the previous image is not erased before scroll or zoom operations. If the background color is partially transparent, the graph fades out partially with every change.

It appears that the graph window is rendered by simply drawing the background and then the visible graph elements without erasing the entire view first.

See http://snag.gy/sb9QL.jpg for a rather dramatic example - background color #ffffff0f, drag the view rectangle around with the mouse in the Overview.

Answer 1

You are right, the graph window is rendered by simply drawing the background and then the visible graph elements without erasing the entire view first. The reason for this is simple: there is no way to "erase" anything. Either you draw something or you do not.

In short, the problem is the fact that we allow non-opaque background colors in the first place. We will fix this to support opaque background colors only.

Thank you very much for bringing this to our attention.

Comments

I really want to be able to export graphs with a transparent background  : o
Disabling transparency would force some sort of tedious workaround (for example, save as SVG and then delete the background element).

Could the drawing procedure be changed instead to draw the background with the color masked with 0x000000FF to force full opacity even though the file will export with transparency?

---

SVG, SVGZ, and PNG export have an option "Transparent Background" on tab "Image" in their export settings. If you select that option, you will get a fully transparent background in the exported file *no matter what background color is used in yEd*. I highly recommend using the aforementioned export setting with an opaque background for yEd's editor tabs because some export formats cannot handle transparency. E.g. JPEG does not support non-opaque pixels, which means that your original approach might result in broken image files.

---

Oh...that's exactly what I wanted in the first place. Well, at least we got a good bug report out of all of this!