How REBOL internally stores transparency information of images?

[rebolbot]

Submitted by: oldes

I should do more tests, but I don't like code like:

back_a = 255 - bg_ptr[Order::A];

https://github.com/carls/R3A110/blob/master/src/agg/agg_span_image_resample_rgba_rebol.h#L130
https://github.com/carls/R3A110/blob/master/src/agg/agg_span_image_resample_rgba_rebol.h#L220
https://github.com/carls/R3A110/blob/master/src/agg/agg_span_image_resample_rgba_rebol.h#L220
https://github.com/carls/R3A110/blob/master/src/agg/agg_span_image_resample_rgba_rebol.h#L504

I believe we should avoid such a operations to speed up REBOL's graphic performance.

^{CC - Data [ Version: alpha 110 Type: Issue Platform: All Category: Graphics Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: Carl

The source of this problem comes from the definition of the color tuple, which is defined:

 1.2.3 => 1.2.3.0

Where "=>" means "implies." This color is opaque (zero transparency), which is what you want.

The alternative is to define:

 1.2.3 => 1.2.3.255

But that would become very problematic for math operations.

If you think of a solution, let us know.

[rebolbot]

Submitted by: oldes

The question is, which operations we do with the pixel more often, if it's when we (re)draw an image, or when we want to get/set a pixel value as a tuple. I guess we do more often the first one, so wouldn't it be better to do the conversion when setting pixel value from tuple and when displaying pixel values in console? But such a change should be made now (when we are still in alpha version).

Btw... pixel manipulations using tuple are slow so everybody who wants to do something serious should avoid it and manipulate directly binary pixel values!