I've got this problem:
I created a pretty large Canvas in WPF with a lot children.
I want to add a Print Button. PrintVisual seems not to work, because the image is to big. (I am using a scrollbar) I want to split the Canvas between multiple pages.
What i've done so far:
I am taking a Visual Brush for every part of the Canvas
Create a new Canvas and make the visual brush its background
Adding the new Canvas to a page, add the page to a FixedDocument.
Well, now i've got a FixedDocument and going to print it via printDocument.
The Problem is, that the whole process of printing takes a lot of time and sometimes it doesn't work at all. It's like there is a preprocessing step to convert the fixed document into a bitmap.
My Question: Is a Visualbrush in a Canvas to big? Should i convert the Canvas first into a bitmap?
I've found this great article: http://www.codeproject.com/Articles/339416/Printing-large-WPF-UserControls.
Whatever.
Is it a good way to convert a huge canvas into a bitmap first and then print parts of the bitmap? I could very well imagine, that one could get problems with blurring effects this way.
I've got also no idea how to add a bitmap to a page in wpf.
The worst thing is, that i couldn't found some really good sorces or a standardway (and i think there has to be one, cause this should be a pretty standard problem) for printing dynamic produced canvas in wpf.
I am really greatful for every really good source, help or code.
Thank you for your time.
Related
I'm making an app for Windows 8.1 where it is important to be able to zoom in and examine images in detail. If I just open up the bitmap and zoom in it looks like.
However when I load the image into my app and use the ScrollViewer to zoom in I get.
As it appears to be trying to interpolate pixel values for some sort of anti-aliasing.
How can I get it so that when I zoom in it shows (as best it can) the exact pixels of the image? In particular I'm using the image as the background to a canvas which is contained in a scroll viewer.
I've looked around on here and MSDN and found a pair of related questions, but as yet they don't seem to have solved my exact problem.
A discussion on WPF
A similar issue with a canvas
Older related question on pixel art
A way to use bitmap encoding (which I couldn't get to work)
Similarly phrased question
There is no easy way to go about this, your best option is to use DirectX to render the image much larger so that you can mitigate the effect of WinRT automatically interpolating pixel values.
As someone explained on MSDN and based on this outstanding request I can't see any other way to accomplish this.
Use Win2D
Win2D is a DirectX inter-op library for WinRT. With this you can render the image at a much larger size, and then set the default zoom level for the scrollViewier to be very small. Because of this when you zoom in it will appear to be that you can see the individual pixels without any fuzzy/blurry interpolation because you will actually be seeing groups of 64 pixels or so all as one color. I couldn't find any way to actually override what kind of interpolation gets done so this seems to be the best method.
Download Win2D as a NuGet package using Visual Studio, Win2D's
quickstart guide does a good job explaining some of the setup
Set up your canvas and the draw event and use the DrawImage function to render the image larger
<ScrollViewer x:Name="Scroller" ZoomMode="Enabled"
MinZoomFactor="0.1" MaxZoomFactor="20">
<canvas:CanvasControl x:Name="canvas" Draw="canvas_Draw" CreateResources="create"/>
</ScrollViewer>
In the canvas_draw function.
canvas.Width = original.Width * 10;
canvas.Height = original.Height * 10;
args.DrawingSession.DrawImage(bitmap,new Rect(0,0,original.Width*10,original.Height*10), new Rect(0,0,original.Width,original.Height), 1.0f, CanvasImageInterpolation.NearestNeighbor);
Make sure to set your canvas to be larger as well
In your code behind set the default zoom of your ScrollVieiwer to be appropriate so your image appears to be the same size.
In the page constructor
Scroller.ZoomToFactor (0.1f);
Other Ways Which I Looked Into and Didn't Work
Making the canvas very large and using BitmapEncoder/BitmapDecoder with the interpolation mode set to NearestNeighbor, this introduced lots of visual artifacts even when scaled to a power of 2 size
Render options only appear to be usable in WPF and not WinRT
It may also be possible to use some image manipulation library to simply make the bitmap 10x or so as large and then use that, but I ended up using Win2D instead.
I have a WinForms application that allows you to edit documents. Each document is made of chapters and each chapter holds a collection of RTF blocks. The RTF blocks are loaded in a PanelControl using Dock = DockStyle.Top.
The problem is that when the total height of a chapter gets too large (estimating > 32768 pixels) the lower blocks are not properly docked: they appear behind one another. When trying to isolate the problem I noticed that this also happens with simpler controls like a LabelControl.
Things I tried are methods like Refresh(), Invalidate() and PerformLayout: they will not resolve the issue.
What does help is resizing the form. After that all controls are laid out correctly.
Can anyone help on how to solve this without resizing the form?
Attached a simple demo-project that illustrates the problem.
From my comment above (seems really to be the problem here):
WinForms (and the GDI in general) is often behaving unpredictably if one tries to use coordinates outside a 16 bit range. Try to avoid that. In the range of possible problems are things just not getting drawn at all, OverflowExceptions at unexpected code positions etc.
If it's possible to you take decision to change this layout, I suggest you to take another approach on showing/editing the documents chapters with some kind of pagination or collapsing RTF blocks into a menu and showing only current.
You see.. it makes a sense the height value be a integer 16-bit value.
A screen is way more tiny than this.
As panel height increases to such a high size. You see that using scroll bar will become very very sensible.. and it's not a good thing.
Content with size 2x, 3x, 5x being scrolled is usable to user. But scrolling a content with height (~32768) of at least (using good resolution monitor w/ window maximized) in optimal case 32x the size of window is very uncomfortable.
Plus, I believe that the productivity of user will decrease due to brain difficulty in locate "things" in a increasing collection of "things".
this is my first question, however I'm a long time lurker. I'll split up this into two parts, one part explaining what I'm doing and why I think this is the way to go, the second one being the actual question that I can't solve for myself.
What am I doing?
I'm currently developing a framework for rendering 2-dimensional features meant to be displayed in real-time. You can think of an application like Google Maps in your browser, however the framework is meant to render all kinds of geographical data (not just axis-aligned raster data, like those Google Tiles).
The framework is to be integrated into our (the company's) newest product which is a WPF application for the desktop and laptop.
Therefore I chose WPF for actually rendering geometry only; Visibility and Occlusion Culling are done by myself as well as input handling (mouse picking), moving the camera, etc..
Being a real-time application, it need to achieve at least 30 FPS. The framework performs adequate when rendering images: I can draw several thousand bitmaps per frame without a problem, however polyonal data turns out to be a major problem.
The actual question
I'm rendering my fair amount of polyline and polygon data using WPF, specifically using DrawingContext and StreamGeometry. My understanding so far is that this is the way to go for if I need performance. However I am not able to achieve the results that I expected from this.
This is how I fill the StreamGeometry with actual data:
using (StreamGeometryContext ctx = Geometry.Open())
{
foreach (var segment in segments)
{
var first = ToWpf(segment[0]);
ctx.BeginFigure(first, false, false);
// Skip the first point, obviously
List<Point> points = segment.Skip(1).Select(ToWpf).ToList();
ctx.PolyLineTo(points, true, false);
}
}
Geometry.Freeze();
And this is how I draw my geometry:
_dc.PushTransform(_mercatorToView);
_dc.DrawGeometry(null, _pen, polyline);
_dc.Pop();
As a test, I loaded ESRI shapes from OpenStreetMap into my application to test its performance, however I'm not satisfied at all:
My test data consists of ~3500 line segments with a total of ~20k lines.
Mapping each segment to its own StreamGeometry performed extremely bad, but I kinda expected that already: Rendering takes about 14 seconds.
I've then tried packing more segments into the same StreamGeometry, using multiple figures:
80 StreamGeometry, Rendering takes about 50ms.
However I can't get any better results than this. Increasing the amount of lines to around 100k makes my application nearly unusable: Rendering takes more than 100ms.
What else can I do besides freezing both the geometry as well the pen when rendering vector data?
I'm at the point where I'd rather make use of DirectX myself than to rely on WPF for me do to it because something seems to be going terribly wrong.
Edit
To further clarify what I am doing: The application visualizes geographic data in real-time, very much like an application like Google Maps in the browser: However it is supposed to visualize much, much more data. As you may know, Google Maps allows both zooming and panning, which requires > 25 FPS for it to appear as a fluent animation; anything less does not feel fluent.
*
Sorry but I shouldn't upload a video of this before the actual product is released. You may however envision something like Google Maps, however with tons of vector data (polygons and polylines).
*
There are two solutions, one of which is very often stated:
Cache heavy drawings in a bitmap
The implementation seems kinda easy, however I see some problems with this approach: In order to properly implement panning, I need to avoid drawing the heavy stuff each frame, and therefore I am left with the choice of either not updating the cached bitmap while panning the camera, or creating a bitmap which covers an even bigger region than the viewport, so that I only need to update the cached bitmap every so often.
The second "problem" is related to zooming. However it's more of a visual artifact than a real problem: Since the cached bitmap can't properly be updated at 30 FPS, I need to avoid that when zooming as well. I may very well scale the bitmap while zooming, only creating a new bitmap when the zoom ends, however the width of the polylines would not have a constant thickness, although they should.
This approach does seem to be used by MapInfo, however I can't say I'm too fond of it. It does seem to be the easiest to implement though.
Split geometry up into different drawing visuals
This approach seems to deal with the problem differently. I'm not sure if this approach works at all: It depends on whether or not I correctly understood how WPF is supposed to work in this area.
Instead of using one DrawingVisual for all stuff that needs to be drawn, I should use several, so that not every one needs to be RenderOpened(). I could simply change parameters, for example the matrix in the sample above, in order to reflect both camera panning and moving.
However I see some problems with this approach as well: Panning the camera will inevitably bring new geometry into the viewport, hence I would need to perform something similar than in the first approach, actually render stuff which is currently not visible, but may become visible due to the camera shifting; Drawing everything is out of the question as it may take ridiculous amounts of times for a rather small amount of data.
Problem related to both approaches
One big problem which neither of these approach can solve is that even if the overall frame-rate is stable, occasional hickups, either when updating the cached bitmaps (okay, this doesn't apply if the cached bitmap is only updated when the camera is no longer panned) or calling RenderOpen to draw the visible chunk of geometry, seem to be inevitable.
My thoughts so far
Since these are the only two solutions I ever see to this problem (I've done my fair share of googling for more than a year), I guess the only solution so far is to accept frame-rate hickups on even the most powerful GPUs (which should be able to rasterize hundreds of millions of primitives per second), a delayed updating of the viewport (in the case where bitmaps are only updated when the viewport is no longer moved) or to not use WPF at all and resort to DirectX directly.
I'm very glad for the help, however I can't say I'm impressed by WPFs rendering performance so far.
To improve 2D WPF rendering performance you could have a look at the RenderTargetBitmap (for WPF >= 3.5) or the BitmapCache class (for WPF >= 4).
Those classes are used for Cached Composition
From MSDN:
By using the new BitmapCache and BitmapCacheBrush classes, you can cache a complex part of the visual tree as a bitmap and greatly improve rendering time. The bitmap remains responsive to user input, such as mouse clicks, and you can paint it onto other elements just like any brush.
I have c# winform application.
I want to print all form objects, labels,textboxes etc..
Capture screen is not the solution for me because my form has scroll.
How can I do this?
Thanks.
A simple google search:
http://msdn.microsoft.com/en-us/library/aa287529%28VS.71%29.aspx
This just doesn't work. It is pretty inappropriate anyway, the resolution of the printer is much better than the resolution of your screen. The screenshot looks very ugly on paper, especially text gets blobby with the anti-aliasing pixels becoming painfully obvious.
Bite the bullet and drop the PrintDocument component on the form. You typically need to write a fair amount of code in the PrintPage event handler. But it isn't hard code and it will look great and you can make it look just the way you want it. Be sure to make it look like a report, not a screenshot. Use PrintPreviewDialog to avoid wasting a lot of paper. Report generators like RDLC and Crystal Reports are common solutions as well.
try this it will make a bitmap of your form `
Bitmap b = new Bitmap(this.Bounds.Width, this.Bounds.Height);
this.DrawToBitmap(b, new Rectangle(0,0,this.Width,this.Height));
b.Save("C:\\a.bmp");`
by this image you can print also rather than saving it...
Currently I'm using a System.Windows.Media.DrawingGroup to store some tiled images (ImageDrawing) inside the Children-DrawingCollection property.
Well the problem is now, this method gets really slow if you display the entire DrawingGroup in an Image control, because my DrawingGroup can contain hundreds or even thousands of small images it can really mess up the performance.
So my first thought was to somehow render a single image from all the small ones inside the DrawingGroup and then only display that image, that would be much faster. But as you might have figured out I haven't found any solution so simply combine several images with WPF Imaging.
It would really be great if someone could help with this problem or tell me how i can improve the performance with the DrawingGroup or even use another approach.
One last thing, currently I'm using a RenderTargetBitmap to generate a single BitmapSource from the DrawingGroup, this approach isn't really faster, but it makes the scrolling and working on the Image control at least a little smoother.
I'm not sure this applies to your problem, but I'll post it here anyway since it might help someone:
If not all of the images in the drawing group is going to be visible at the same time, you could set the ClipGeometry property to whatever you want it to draw. This effectively tells WPF that the parts outside of the geometry is not needed and will be skipped during rendering.
A few other things you could experiment with are:
Freeze the drawinggroup before applying it to your image source. At least it couldn't hurt (unless you really need to modify the instance, but remember you could always just create a new one instead of modifying the old)
Try different ways to display your drawinggroup. For instance as a DrawingVisual (which is considered light weight) or as a DrawingBrush to paint e.g. a rectangle.
Combine the small images into smaller groups which you then combine to your bigger group. No idea if this improves or hurts performance, but it could be worth trying.
I'm working on a problem having to do with tiled images, with the added complication of having to display some images overlaid on others.
I haven't run into any performance issues (and likely won't since my images are rather small and relatively small in number, around 100 max.), but I did come across the Freeze method in a code sample for the DrawingImage class. The comment for it was "Freeze the DrawingImage for performance benefits."
The Freeze method also applies to the DrawingGroup class. Maybe give it a try?