so I'm challenging myself by making a game-engine using GDI.
So far I've managed to make made a few games using GDI - however I have recent hit a problem I'd like some help with.
I have implemented a UI system and have found out that the GDI Translate function moves the entire canvas. Subsequently all my mouse coordinates are offset causing my UI system to not work as expected.
Question: Is there any way to make a Panel transparent on the Paint method?
I have tried to set the clear colour to transparent but that only makes the panel black.
I cannot point to a source for this, but I did some testing now and my explanation is as following:
When I set the BackgroundColor of the panel to Colors.FromArgb(50,0,0,0) then this worked, because whenever I changed the Backgroundcolor of the Form the panel lives on, then the color of the form shined through the panel.
But: the other controls that lived behind this panel have not been visible all the time. I am sure that for performance reasons the rendering of the controls only happens if they are visible to the user, that means they are not coverd by an other control. So the color of the form is shining through because the transparent color actually works, but the controls behind the panel are not rendered because they are covered by an other control.
You have to write your own control:
public class TransparentPanel : Panel
{
protected override CreateParams CreateParams
{
get
{
var cp = base.CreateParams;
cp.ExStyle |= 0x00000020; //WS_EX_TRANSPARENT
return cp;
}
}
}
this tells windows, that the control is transparent and the controls that are are in z-order behind this control have to be rendered, too.
I have an application in which I can move from 1 user control to many user controls. When I was moving to many controls, I was getting flickering issues.
To solve the flickering I enabled Double Buffering via -
protected override CreateParams CreateParams
{
get
{
CreateParams cp = base.CreateParams;
cp.ExStyle |= 0x02000000; // Turn on WS_EX_COMPOSITED
return cp;
}
}
It indeed solved the issue of flickering. But introduced a new problem, In which sometimes my user control isn't painted completely. A black window is appeared. To solve this, I need to minimize and maximize the software and it appears properly.
What I think is that, while double buffering is painting all the user
controls at one shot, One or more user control is still generating its
controls. And at the time of master painting, that control was not
ready.
Here is the image for getting proper idea -
As shown in image, There is one form, containing 4 user controls in this particular scenario. Each user control further, contains other controls/user controls.
What is probably going wrong in this issue?
I solved this by changing TrasnsparencyKey in form design from black to another color but not black, try one color that you are not using.
My requirements:
A control with a background can have sprites drawn on it.
It needs to be possible to move sprites around programmatically and by setting up dragging events.
The sprite's image may have alpha transparency; sprites must correctly alpha-blend with both the background and each other.
Drawing order must match the logical order of sprites - clicking on a sprite that appears to be on top should initiate dragging that sprite, never one that appears underneath it.
Attempt 1
The obvious approach is to create a custom control to represent the Sprite. Let's try it:
public partial class Sprite : Control
{
public Sprite()
{
InitializeComponent();
For testing purposes, we'll make it so clicking a Sprite just brings it to the front, no dragging yet:
this.Click += Sprite_Click;
}
void Sprite_Click(object sender, EventArgs e)
{
this.BringToFront();
}
So we can identify each sprite and verify the drawing order, let's set a 'frame' color for each:
public Color FrameColor { get; set; }
And draw the sprites as a translucent white body with a solid-colour frame - we should then be able to verify that the background appears shaded behind a single space, shaded more strongly where sprites overlap, and the borders overlap as expected:
protected override void OnPaint(PaintEventArgs pe)
{
Graphics g = pe.Graphics;
g.FillRectangle(
new SolidBrush(Color.FromArgb(128, 255, 255, 255)),
DisplayRectangle
);
g.DrawRectangle(new Pen(FrameColor, 10), DisplayRectangle);
}
And then we can design a form with a dark background, set up a few Sprites on it, make them overlap, give them different frame colours, and test.
Naturally, it doesn't work. Controls by default have a background colour, which appears to default to white, or something close to it. So these sprites overlap properly, but they have opaque white middles.
Attempt 2
Well, surely we can just set that background colour to transparent? A bit of Googling in Microsoft's documentation tells us that we certainly can, but not directly (as someone else on SO found out the hard way). It needs a bit of configuration:
// in constructor
SetStyle(ControlStyles.SupportsTransparentBackColor, true);
this.BackColor = Color.Transparent;
Okay, so now the background shows through each Sprite, but the Sprite borders don't show through each other. What gives? A little more Googling tells us that this 'transparent background colour' support is actually a bit of a hack; basically, the parent Control implements its background painting to copy image data from the parent component and composite with that, ignoring everything else.
To be totally honest, I expected the system to be designed such that this would just work automatically - i.e., any time any drawing occurs, it composites with whatever's underneath it on screen, and the only reason controls aren't constantly showing through each other is because of their explicitly opaque backgrounds. But no such luck. I guess the whole system was designed back when people didn't want that sort of thing by default, for performance reasons.
Anyway.
Attempt 3
Well, if the background painting is what's causing the problem, maybe we can just disable it completely?
protected override void OnPaintBackground(PaintEventArgs ignored) { }
Nope. If we click on sprites, we can see them re-order, and composite with each other - but they don't composite with the background image. And, more strangely, when the parent window is invalidated (by resizing the form, or minimizing and restoring it), the sprites turn opaque again.
Attempt 4
After even more Googling, we find StackOverflow answers like this and this, articles like this etc. And they all point at the same low-level hack:
protected override CreateParams CreateParams
{
get
{
CreateParams cp = base.CreateParams;
cp.ExStyle = cp.ExStyle | 0x20;
return cp;
}
}
For this to work, we also need to disable painting the background, but of course it no longer matters if we set up that "transparent" background, since that painting logic has been suppressed. (Curiously, it's also possible to suppress painting the background by setting an Opaque option in the ControlStyles; while that sounds like the opposite of what we want, it seems to work about as well.)
Well. It almost works. The Sprites composite both with themselves and the background. But now a very curious thing happens: the drawing order is wrong, and not even consistent. Invalidating the window in different ways (resizing vs. minimizing and restoring) will bring a different Sprite to the front visually; but in general it doesn't correspond to what was clicked and in what order. If we add explicit invalidation logic:
// in click event handler
Parent.Invalidate(this.Bounds, true);
then clicking a sprite actually appears to send it to the back visually - although again, the drawing order may change if we resize the window or minimize and restore it.
What gives? How can I solve this once and for all? Options I've considered:
Burn the controls to the ground; make a parent control keep track of a list of sprite Images, track mouse drag and click events, and do all the picking and rendering logic itself. Should be guaranteed to work, but is a ridiculous amount of work for the job.
Make the controls not draw at all, by overriding both background and foreground painting, and have them expose a property with their desired Image. Let a parent handle all the rendering, but fall back on the built-in Control logic for picking, mouse drags etc. Less work, but seems iffy (maybe there's some hidden thing that still forces Controls to draw something?), is a fairly tightly coupled design, and might still have performance issues if a naive approach is taken to invalidation (?).
After even more research, I appear to have an answer.
First, some explanation about drawing order: as far as I can tell now, it was consistent in Attempt 4, but invalidating by resizing the window causes gradual invalidations of different areas, which produces misleading results. The order is always top to bottom, which is the opposite of what you want for compositing, but which enables optimizations when you treat everything as opaque by clipping the invalid regions. (I'm not sure how much CPU effort this really saves given that the clipping paths can potentially get quite complex, but I guess it also helps reduce flickering when you aren't using double-buffering, since you avoid repainting a given pixel on any given refresh.)
But as it happens, if you read between the lines, you discover that there is another flag in the "extended window styles" (the 0x20 flag that we set in Attempt 4 is WS_EX_TRANSPARENT), called WS_EX_COMPOSITED (value 0x02000000), that reverses the drawing order to be what we want instead. Or you could have just read the documentation more closely in the first place. Oops.
(You'd think they could have just designed it to take care of all this logic automatically - detect which sprites have a translucent or transparent background colour, draw the ones with opaque backgrounds top-down first for speed, then the others bottom-up for correctness while clipping around the opaque ones. Oh well.)
A quick note here: because compositing naturally involves repainting the same area multiple times, this flag also sets up double-buffering that applies across all children of the window created with that flag (as far as I can tell, in Windows API parlance, every control is a "window", as well as the forms themselves). So it seems that people often use it to avoid flickering on forms with lots of controls, even when they don't intend for controls to overlap. However, ironically, WS_EX_COMPOSITED might actually cause huge amounts of flickering with certain controls, such as TabPage. (I'm running 8.1 and was able to reproduce the described problem very clearly.) The documentation states
This cannot be used if the window has a class style of either CS_OWNDC or CS_CLASSDC.
So maybe that has something to do with it. We can avoid this by restricting the "composited area" to a region using a simple control such as a Panel. At least in my tests, that will fix the problem as long as the TabPage isn't a child of the Panel, even if it overlaps.
It also seems that this might not work under XP, but hey, it's 2014 now.
Anyway, on to the code.
What we need to do is set a CreateWindowEx flag, with the same CreateParams technique, in some ancestor of the Sprite, such as the Form they're on:
protected override CreateParams CreateParams
{
get
{
CreateParams cp = base.CreateParams;
cp.ExStyle = cp.ExStyle | 0x02000000;
return cp;
}
}
We still need the WS_EX_TRANSPARENT setting, and disabling of background paint on the Sprite controls, from attempts 3 and 4. We don't need to set up a transparent BackColor, because we're not going to paint the BackColor. I have no idea why allowing a fully transparent BackColor to be painted messes things up, but it apparently does.
This will apparently work even if there are intervening controls, i.e. if we put the Sprite controls inside a Panel on the Form. (If we want to restrict the effect to a Panel, as discussed above, we'd have to subclass Panel; but my project already does so :) ) Everything works perfectly in my test project, and I don't even need to explicitly Invalidate anything.
I have an image that I wanted to include in my vb.net app, so I sliced it up in photoshop and divided it into multiple picture boxes, and anchored them accordingly so when my application is resized it wont stretch all parts of the image. That is all good, it looks great and almost works great..except the fact that when the form is being resized it is causing the pictureboxes to flicker.
I know that the picturebox is not the fastest control, so I am geussing it is not refreshing fast enough. Aside from flickering it appears with a white background underneath even though the pictureboxes are transparent.
I tried adding a BG colour for the background hoping it would hide the flickering better while loading to no avail.
So my fist question would be is their any way of preventing this? If not is their a control that is faster that I could use?
Maybe a custom picture box someone knows, or even if you know a control thats faster. Basically any control that would allow a background image and transparent BG color would work as long as it is faster.
I really appreciate any help. Thanks. PS: My application is in VB.net but I am adding a C# tag aswell because I am most likely going to have to switch controls instead of repairing it through code.
Two avoid flickering in controls in form u can use following function
Only copy it and paste it anywhere in form.vb
Protected Overrides ReadOnly Property CreateParams() As CreateParams
Get
Dim cp As CreateParams = MyBase.CreateParams
cp.ExStyle = cp.ExStyle Or &H2000000
Return cp
End Get
End Property 'CreateParams
only paste anwhere it is readonly property
Two ways to handle this are:
a) Resize the image in the picturebox so it is smaller and will redraw faster, or
b) Use a timer to redraw the image so it doesn't begin to redraw until 100 to 350 ms after the last resize event.
I am using a library in which enables me to animate movement of WinForm elements (linked below), when I use it to move a transparent panel across the form (which has a picture background) there is an extraordinary amount of tearing.
I believe the fix is to get winforms to refresh at a rate of 30fps without being laggy. I tried settings a timer to do This.Refresh(); at 30 times a second but it just ended up with slow loading. So how would I achieve a nice refresh rate of the form?
The link described above is here -> http://code.google.com/p/dot-net-transitions/wiki/CodingWithTransitions#Creating_a_transition_that_works_on_a_single_property
Here is an example of the tearing. It might have something to do with the fact that the panel's backcolor is set to "transparent"
http://screencast.com/t/XIr3NkGI
I used this ages ago when I had trouble with controls on a form flickering, in my case there were many controls and when loading the form the controls would flicker quite badly.
In the end I used this:
protected override CreateParams CreateParams
{
get
{
CreateParams cp = base.CreateParams;
cp.ExStyle |= 0x02000000;
return cp;
}
}
Paste that in your form.
It activates double buffering at the form level and for all controls within it.
HOWEVER, while it stopped my flickering issue it greatly reduced the speed at which the forms elements seemed to move as they don't get drawn until they are 100% ready.
I guess you can try and see if it suits your situation.