I currently have the problem to display a OffScreen Control in a WPF context.
I could use the WPF control given by cefsharp, but the problem is that the control only gets initialized when drawable (which is a problem).
Rendering a image is no big deal, but want to display a series of images (no high framerates is needed), also should it not eat the whole performance on the computer while doing this.
Best regards,
Sebastian
Related
I am writing an application that renders an OpenGL scene. This application has two windows:
A large window that shows only the rendered scene
A "control window" that offers several settings and a preview of the rendered scene
This application is written in .NET (for the control window part) and uses a native C++ DLL to create the rendering window and do the actual OpenGL rendering.
This works fine, but one important part is still missing: getting a live preview of the rendered scene into my .NET control window.
So far I could think of two solutions:
Render the scene not only to the screen, but also to memory. Then shove that blob of memory to my .NET WinForm. Finally draw the image to a PictureBox or something. <- This sounds horribly slow!
Make my native OpenGL renderer render the scene twice, once to the native full size window, once to a control (panel?) on my .NET form.
Option 2 sounds faster, but I have no idea if/how that even works.
Can this be done? Are there better alternatives?
Look into the documentation on framebuffers. It is basically the destination of your rendering, by default it's your viewport (or the backbuffer, which switches with the displayed buffer once it's ready).
The first option should generally be faster as you render the scene once and then just basically copy a texture.
I would like to overlay own content above a Direct3D v9 game (made by a third party).
Overlay Interactive Button
Specifically, I would like to overlay a clickable button control, like Steam does, for instance, though I'm attempting a much simpler interface.
Ideally, I would be able to overlay a WPF button or a Windows Form button or whole UserControl, but if that is not possible then creating a functioning button from primitives would suffice as well.
Text Overlay Working with SharpDX
I have a working sample of overlaying text based on the work of Justin Stenning
Namely with the help of SharpDX.Direct3D9.Font DrawText method
How to Overlay a Button or UserControl with SharpDX
I looked through relevant samples in https://github.com/sharpdx/SharpDX-Samples but was not able to find a way to include or draw native controls with SharpDX
Is it possible?
If not, are there any samples of drawing a clickable button from scratch?
Please bear in mind I'm a novice in the DirectX world :)
Your biggest problem isn't going to be getting the controls to render on top of a DX scene; it's going to be getting them to respond to input afterwards. You can probably rig up a way to get the visuals copied to a DX surface, but I have no idea how you would capture input, translate it, and deliver it back to the WPF components. If it's even possible, it's almost certainly more trouble than it's worth.
There are a couple game-oriented Xaml solutions out there that you may want to check out. WPF for Games is a partial C++ implementation of WPF based on Direct3D, and there's also the proprietary Noesis GUI.
I've been searching for a long time without finding a proper answer to this question. Maybe because it can come up with the right keywords to search for.
However, I have a WinForm with a ElementHost containing some WPF (A UserControl). In WinForm can be resized and I want the WPF to have a different layout/view depending on if the window is in landscape or portrait mode.
What is the best way to design a layout like this in WPF?
I will do the detection of the window aspect ration in my winform OnResize(System.EventArgs e) and send the signal downwards into my ElementHost. The layout should be switched and replaced at runtime.
Pardon me if the terminology is not correct but I'm a bit new to the .NET framework.
I am currently working in Windows Form Apps and am making what will essentially be a map editor for a game. The way i have gone about this is by having a central TabControl where each TabPage contains a custom PictureBox control and all the other UI controls are around this central TabControl. The PictureBox uses its Paint event to draw everything that is placed on the map, and therefore draws multiple images of many sizes, rotations and scales etc to the single PictureBox. This has all gone well so far. The TabPage is essentially used as a view window for the PictureBox and is of size (1280x720).
The problem is with the scale to which the maps are being produced. The avg (and also maximum) map size on screen is around 19200x10800px and can be made up of hundreds of items at any one point. When drawing just a backdrop image of size 19200x10800px the PictureBox starts to flicker when it redraws and makes the program unusable. As the map is so big you are able to pan around them and this is where the flickering really shows. Also i do not want to use a 19200x10800px image source if possible for the sake of file sizes and the scaled image quality isn't an issue at all.
I have done heaps of reading on why this might be and feel like I have tried everything up until this point. So far ive tried:
Having the background image only 1920x1080 and scaling it up by 10x
Starting with a 1920x1080 image, programatically resizing it and drawing this image
Slicing the background into multiple segments (i tried many different amounts) and drawing only the ones that the view window can see (tried this for both a small(1080p) and large(10800p) images)
Using graphics clipping so that only the things on screen would be drawn
Used Double Buffering on both the picturebox and the form that the picturebox is on
Converting the image at initialisation to an "optimised bitmap" with faster formatting and then drawing the bitmap
I've probably tried a couple other things along with minor optimisations but its taken me so long ive forgotten the rest. From what i've read its most likely something to do with the control redrawing too slowly for some sort of performance reason or a limitation with picturebox's, however exactly what is going on i cannot tell due to lack of experience with form apps controls.
Currently to draw the background in the Paint event i have either:
g.DrawImage(image, new Rectangle(0, 0, (int)(image.Size.Width * levelScale), (int)(image.Size.Height * levelScale)));
or
g.ScaleTransform(levelScale, levelScale);
g.DrawImage(image, new Rectangle(0, 0, (int)(image.Size.Width), (int)(image.Size.Height)));
Where g is the Graphics object.
Have I hit the limit of Win form apps capabilities or is there something i may be missing?
Any and all help appreciated,
Thanks in advance.
Just for formality I though id answer my own question just in case anyone else would like to know the outcome.
Based off the overwhelming consensus that winforms was just not made to do the things I was trying to do with it I decided I had to move to some other platform. Suggested to me was WPF, DirectX and OpenGL but after some extensive searching around I found what I think is the optimal solution.
In order to utilise the power of DirectX hardware acceleration MS has made it so that you can embed XNA graphics devices into a winforms application. Essentially you can create custom controls that run in the normal winform style that have access to a much higher caliber of graphics control. In this manner (with a bit of extra work) I have replaced the picturebox I was using with a custom graphics control which handles all of the drawing. This has worked very well, and on the up side i havent had to take too much of a hit to my development time.
For those looking for more info refer to this question which has further links that should help. Once again thanks to all those who gave their advice!
This is a quoted answer from the URL at the bottom. There are code examples at the link at the bottom. Hope this is helpful; not sure if you tried this yet and maybe it'll help you get a little more juice out of the existing picturebox control. As explain in the other answers, it sounds like you will be forced to a more powerful solution in the near future regardless (DirectX/OpenGL or WPF)
** Partial quote from http://social.msdn.microsoft.com/Forums/en-US/68ecd1f6-2eeb-45ce-a881-24c62145ab0e/c-picturebox-problems
"I'd guess the real problem is that it takes too long to redraw the images. GDI+ is pretty slow, it doesn't use any video hardware acceleration. To speed it up, be sure to avoid rescaling the drawing and to use the Format32PArgb format. It is about 10 times faster than any other format. Load the images into a Bitmap with the right format first."
If you have a LOT of items (Maybe realized as controls), forget about the standard event mechanism of Windows Forms. Some time ago, i've written a logic gate editor/simulator which supported lots of thousands of gates in the editor and was really fast. There, I've used the canvas and draw the gates as custom "images" instead of putting them as controls. You'll have to write a custom GetUnderlyingGate function which resolves the current gate / tile (Is your editor a tilemap editor?) from a coordinate array. Also, there were some visible area optimizations.
Maybe, when i'm back home, I'll upload some sourcecode and notify you.
We have a bunch of forms with alot of PictureBoxes on them. They're basically a representation of an engineering system with pipes connected to pumps and whatever. Each element is it's own picturebox, so there's a few hundred.
The problem we have is that when we take the app to a large 40"+ TV, there's too much space everywhere and it doesn't look the way it does on the developer's screen. So we designed it for these large TV's but when we look at it on a normal computer screen it's all wrong.
So how do we design the form with pictureboxes for the actual images to resize and reposition the controls relative to the size of the resolution it's being viewed on? If we simply anchor everything then the image sizes themselves are not relative to the display it's seen on.
Much appreciated!
In a Winforms solution you will have to do at least some of the resize calculations if anchoring and docking do not provide you with the required results.
If it is really important to you to be able to design the UI in Visual Studio I recommend writing custom controls that expose the desired resize properties and resize behavior and perhaps even a custom designer to support the design time features.
It might not be feasible but you could consider having a look at WPF, it has a ViewBox control that might simply be the answer to your needs.