Opened 4 years ago

Last modified 2 months ago

#12931 new bug

Spirograph (BeOS app) doesn't draw its background transparent

Reported by: jscipione Owned by: jscipione
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by jscipione)

Draws spirographs similar to a popular toy. Problem as stated by packager:

"But the transparency does not work on Haiku, so you will only see the top layer."

I've included some screenshots

Attachments (3)

spirograph_med.jpeg (94.4 KB ) - added by jscipione 4 years ago.
Screenshot on BeOS
Spirograph.png (134.3 KB ) - added by jscipione 4 years ago.
Screenshot on Haiku, notice the color #777477 which is B_TRANSPARENT_COLOR's hex value
Spirograph-1.5-src.zip (25.6 KB ) - added by jscipione 4 years ago.

Download all attachments as: .zip

Change History (9)

by jscipione, 4 years ago

Attachment: spirograph_med.jpeg added

Screenshot on BeOS

by jscipione, 4 years ago

Attachment: Spirograph.png added

Screenshot on Haiku, notice the color #777477 which is B_TRANSPARENT_COLOR's hex value

comment:1 by pulkomandy, 4 years ago

Peeking at the window/view structure with hey may provide some hints: how the views are laid out, which drawing modes they are using, etc.

by jscipione, 4 years ago

Attachment: Spirograph-1.5-src.zip added

comment:2 by jscipione, 4 years ago

This appears to be the malfunctioning bit of code

int32 DrawView::Rewrite_image(DrawView*  data)
{
	rgb_color Transparent;
	memcpy (&Transparent, &B_TRANSPARENT_MAGIC_RGBA32, 4);

		// We'll add a drawing view to the bitmap
	int i;		// Index for the loop - we'll need it later
	BView* drawer = new BView (
		data->image->Bounds(),
		"drawer",
		B_FOLLOW_LEFT | B_FOLLOW_TOP,
		B_WILL_DRAW | B_SUBPIXEL_PRECISE);
			// If allocated successfully, add it to the bitmap
	if (drawer != NULL) {
		data->image->AddChild(drawer);
	}

			// Now, adding the image layers, one by one
			// The drawing mode must be set to B_OP_MODE, for the LowColor
			// of the drawing shall be treated as transparent.
			//
			// I must acquire the lock!
	if ( drawer->LockLooper() ) {
		drawer->SetLowColor(Transparent);
		drawer->SetViewColor(Transparent);
		drawer->SetDrawingMode(B_OP_OVER);
		for (i=0; i<MAX_LAYERS-1; i++) {
				// If current layer is not empty
			if ( (data->layers[i] != NULL) && ( (int )data->layers[i] != 0x19) ) {
					// Adding it to the bitmap, in B_OP_OVER mode
				drawer->DrawBitmap (data->layers[i]);
				drawer->Sync();
			}
		}
		drawer->UnlockLooper();
	}
	else {			// If I can't lock the BView, I alert the user.
		BAlert* cantLockLooper = new BAlert(NULL, "Cannot acquire the lock on the drawing element!", "Ok");
		cantLockLooper->Go();
	}

	// Now we may successfully delete the "drawer" BView
	data->image->RemoveChild (drawer);
	delete drawer;
	drawer = NULL;

	exit_thread(0);
	return 0;
}

comment:3 by jscipione, 4 years ago

Description: modified (diff)

comment:4 by diver, 6 months ago

Was it fixed in hrev53713?

in reply to:  4 comment:5 by X512, 6 months ago

Replying to diver:

Was it fixed in hrev53713?

In version 1.5 built from source issue is still present.

comment:6 by pulkomandy, 2 months ago

I fixed it by changing the initialization of the bitmap in spirograph: at line 1215, SetBits is called with B_RGB32 colorspace, so the alpha channel is masked. There are comments in our SetBits implementation saying that B_RGB32 would import only 24 bits from the data, that doesn't seem to be exactly correct then?

It doesn't look perfect still due to the antialiasing being performed with the wrong color and the drawing not being done with alpha channel, but that's expected with the way the app works (BeOS had no antialiasing).

We can try to fix SetBits, it's already BeOS specific and ImportBits is used by Haiku apps because it makes more sense.

Note: See TracTickets for help on using tickets.