this may seem like an odd question, and I don't know the formats of images so I'll just go ahead and ask...
I'm making a minesweeper game (relevant to different things too) which utilizes a grid of buttons, then I'm adding a sprite to the buttons using backgroundImage. If the grid is 9x9 it's fine. 15x15 it slows down and 30x30 you can visibly see each button being loaded.
That raises me to my question: Which image format would load fastest? Obviously, file size takes a part in the loading speed, however, I am enquiring as to if, say, a jpeg - with the same filesize as a gif - will load faster. or a bmp, png, etc.
I'm asking this as to see if I can get my grid to load faster using a different format.
Thanks!
You want an image format that paints faster. There's only one, the one whose pixel format directly matches the video adapter's setting so that the pixel data can be directly copied without needing format adjustments.
On most any modern machine, that's PixelFormat.Format32bppPArgb. It draws ten times faster than all the other ones.
You won't get that format when loading an image from a resource or a file, you have to create it.
Do note that this still won't give you stellar paint speed if every cell in the grid is a control. Particularly if it is a button, they are very expensive to draw since they support transparency effects. You'll only get ahead here if you draw the entire grid in one Paint event handler. Like the form's.
A completely different approach is to cover up the visible delays with this hack.
use the 8-bit PNG or GIF format and reduce the number of colors in the palette. Some image programs such as PhotoShop allow you to save the image for the web and fine-tune the image settings. By reducing the color palette from 256 to something like 32, you greatly reduce the size of the file. The less colors that the image has, the smaller the file size is going to be.
PNG has a similar feature called "Interlaced". You may want to turn this feature off so that the full image downloads quicker.
Because the 8-bit PNG and GIF formats have the potential to result in much smaller image files, try to keep this in mind when creating graphics and illustrations for your application. Try to keep the amount of colors to a minimum and use flat graphics instead of photographs. This way you can create images with palettes of 16 colors, keeping the file size extremely small and fast to load.
Best Regards
Are you reloading the image every time you paint a button? If so, there's your problem - solve it with a cache.
Are you painting the image at its native size? Runtime resampling can create a performance hit.
use PNG or GIF it's faster types of images
Related
I'm creating a map editor for game in C# Windows Forms. What I need is a grid that will have to store even a few thousands of images.
My first approach was to create a Panel control and then add multiple PictureBoxes to it. Unfortunately 2000 images took about 3 seconds to draw.
Then I decided to try creating Rectangles and drawing Images on them in Panel's OnPaint() method in hope to get better results but it's still very slow.
Is there any better, efficient way to render so many images in Windows Forms?
Thanks in advance for any advices.
Use the Paint event as you have done but...
As part of the loading of the images, cache a zoomed out version where you merge 16 images into one, which is only 125 images, when you zoom out over a certain scale, switch to using the pre-rendered zoomed out version.
You can do that as often as you like for multiple zoom levels with the idea of keeping as few images as possible on screen at anyone time. So you could divide it by 4 again.
I do this for a project which has a map comprised of 65536 images (256 x 256). The cache is also writted to disk so each time you zoom out you see the same number of images. In my editior I can only view 16 images at any one time, even if I'm looking at the whole map.
You can further improve on the this by knowing the available options to the user (e.g. Pan and Zoom) this gives you a limited subset of images the user could potentially view next so you can preload these to improve performance.
You'll increased load time initially but I bet you already have a significant load time pulling 2000 images off disk
I know it's recommended to convert images to XAML as they become blurred when changing the dpi.
What about standard ICO files which actually are really BMP files?
I need to use these in a toolbar. Do I need to convert all to XAML?
Is there a better way?
What about a similar feature in HTML called sprites where it's one big image but you get items via positions?
Essencially you work with static images when no scaling is needed, and you work with Vector Images when you want to perform all sorts of scaling. This is the rule of thumb for most WPF and Silverlight applications.
However you can't directly convert a static image to a Vector Image (what you call XAML), and most times it will require a designer to do some work on the Vector Image.
Working with vector images makes the rendering process heavier, the more vectors, the slower the rendering pass. It also makes it slower to instanciate a particular Visual Tree, when you add it to something already on screen. This can be overcome if you call RenderToBitmap and cache the sizes of the Vector Images you want to use, but this requires aditional custom code.
Working with static images allows for much faster renders. However upsizing will cause pixelization and downsizing may cause artifacts on the image. When you work with static images PNG is considered to be the prefered format, you have full control over the compression, you have alpha key and it's an indexed format which makes it fairly small in size.
I always convert all images to XAML where it's possible. I think it's good rule.
I am working on Image Viewer application and planning to build in WPF. My Image size are usually larger than 3000x3500. After searching for week, I got sample code from MSDN. But it is written in ATL COM.
So I am planning to work and build the Image viewer as follows:
After reading the Image I will scale down to my viewer size, viwer is around 1000x1000. Lets call this Image Data as Display Data. Once displaying this data, I will work only this Display data. For all Image processing operation, I will use this display data and when user choose to save the image, I will apply all the operation to original Image data.
My question is, Is is ok to use Display data for showing and initial image processing operations.
Yes of course. It will speed things up. The only drawbacks are:
Having to replicate the operations on the real bitmap, and
Losing quality if the user zooms in while editing.
These are tradeoffs you'll have to weight against the better performance of the smaller bitmap.
I have a winforms ImageList which contains 200 256x256 images.
When I add the images, 1 by one, half of the programs time spent on the Add method according to ANTS .NET profiler.
So the program takes 10 secs to launch and 5 is spent there. That is very slow in my opinion.
I implemented the same thing using ImageList.Images.AddRange. The result did not change.
Does anyone know any alternatives or optimizations to solve this? Is the WPF ImageList any faster? Is there a faster winforms ImageList?
EDIT:
foreach (string imageFile in images)
{
imageList.Images.Add(Image.FromFile(imageFile)); // takes pretty much all of program's execution time.
}
Have a look at the album and list views in PhotoSuru, one of Microsoft's WPF sample applications. They have a couple different thumbnail view screens that load pretty quickly (all the images are loaded asynchronously, and only the images necessary are loaded). And there's full source code to get you started if it's what you are looking for.
It not precisely like Picasa (they decided only to show full rows of photos instead of a partially covered row like Picasa), but by implementing your own virtualizing IScrollInfo panel (reasonably straightforward, and Ben Constable has a great series of posts on it), you should be able to get the performance you're looking for and the behaviour you want.
A final note: You might be doing this already (are your images stored as 256x256 pixel images?), but whenever you're trying to display image thumbnails, you'll want to avoid loading the full image. Reading 2 MB+ image files off of the disk just to render an entire screenful of 256x256 pixel thumbnails always has a bigger performance hit than reading an appropriately sized small thumbnail image instead. If you can, cache the thumbnails somewhere (like Windows and Picasa do), or at the very least, try to use the embedded thumbnails in any JPEG files you encounter.
Are you using a ListView for the UI part using that ImageList?
The general solution to these kind of problems is to only load some of the images, because only some of them are shown at a time, and then load the other as needed. ListView has a VirtualMode property for this kind of scenarios.
Loading and adding 200 images at once may be too much to do, you could load the first shown images and then use a background thread to load the others. Have a look at how Win7 display images, it shows some placeholder when you scroll and then, when the image is loaded it shows the real picture. Be warned that this is not a simple thing to do.
try my code here to scale-down your image and make a thumbnail out of it.
Yes it is. Load images to List<Image>. Then call ImageList.Images.AddRange(list).
List<Image> list = new List<Image>();
foreach (string imageFile in images)
{
list.Add(Image.FromFile(imageFile));
}
imageList.Images.AddRange(list.ToArray());
I'm working on a wallpaper application. Wallpapers are changed every few minutes as specified by the user.
The feature I want is to fade in a new image while fading out the old image. Anyone who has a mac may see the behavior I want if they change their wallpaper every X minutes.
My current thoughts on how I would approach this is to take both images and lay one over the other and vary the opacity. Start the old image at 90% and the new image at 10%. I would then decrease the old image by 10% until it is 0%, while increasing the new image by 10% until 90%. I would then set the wallpaper to the new image.
To make it look like a smooth transition I would create the transition wallpapers before starting the process instead of doing it in real-time.
My question is, is there a more effective way to do this?
I can think of some optimizations such as saving the transition images with a lower quality.
Any ideas on approaches that would make this more efficient than I described?
Sounds like an issue of trade-off.
It depends on the emphasis:
Speed of rendering
Use of resources
Speed of rendering is going to be an issue of how long the process of the blending images is going to take to render to a screen-drawable image. If the blending process takes too long (as transparency effects may take a long time compared to regular opaque drawing operations) then pre-rendering the transition may be a good approach.
Of course, pre-rendering means that there will be multiple images either in memory or disk storage which will have to be held onto. This will mean that more resources will be required for temporary storage of the transition effect. If resources are scarce, then doing the transition on-the-fly may be more desirable. Additionally, if the images are on the disk, there is going to be a performance hit due to the slower I/O speed of data outside of the main memory.
On the issue of "saving the transition images with a lower quality" -- what do you mean by "lower quality"? Do you mean compressing the image? Or, do you mean having smaller image? I can see some pros and cons for each method.
Compress the image
Pros: Per image, the amount of memory consumed will be lower. This would require less disk space, or space on the memory.
Cons: Decompression of the image is going to take processing. The decompressed image is going to take additional space in the memory before being drawn to the screen. If lossy compression like JPEG is used, compression artifacts may be visible.
Use a smaller image
Pros: Again, per image, the amount of memory used will be lower.
Cons: The process of stretching the image to the screen size will take some processing power. Again, additional memory will be needed to produce the stretched image.
Finally, there's one point to consider -- Is rendering the transition in real-time really not going to be fast enough?
It may actually turn out that rendering doesn't take too long, and this may all turn out to be premature optimization.
It might be worth a shot to make a prototype without any optimizations, and see if it would really be necessary to pre-render the transition. Profile each step of the process to see what is taking time.
If the performance of on-the-fly rendering is unsatisfactory, weigh the positives and negatives of each approach of pre-rendering, and pick the one that seems to work best.
Pre-rendering each blended frame of the transition will take up a lot of disk space (and potentially bandwidth). It would be better to simply load the two images and use the graphics card to do the blending in real time. If you have to use something like openGL directly, you will probably be able to just create two rectangles, set the images as the textures, and vary the alpha values. Most systems have simpler 2d apis that would let you do this very easily. (eg. CoreAnimation on OS X, which will automatically vary the transparency over time and make full use of hardware acceleration.)
On the fly rendering should be quick enough if handled by the graphics card, especially if it's the same texture with a different opacity (a lot of graphics rendering time is often loading textures to the card, ever wondered what game loading screens were actually doing?)