When GDI+ came out, I remember all the brouhaha about how it was the "new, faster, better" way to display stuff in Windows. But everytime I looked at it, it seemed to me that it was really just a COM wrapper around GDI.
Is that true? Or is GDI+ really an independent graphical library that simply shares some paradigms with GDI?
Personally, I'm not sure how it could be independent, but I never saw a definite statement one way or another.
GDI+ is built over GDI, and adds several more features. For example, GDI+ adds support for transparency, anti-aliasing bitmap stretching, etc...
GDI+ is mainly a Object based API, and GDI is a function api. Most of the functionalities in GDI+ are not hardware optimized (there are handled by software), to contrast with GDI. For example, in GDI, BitBlt is handled directly by hardware. GDI+ bitmap painting functions are not.
GDI+ is a powerful API, but be careful with its performance.
GDI+ is available in C++, COM and .NET
Many GDI functions are accelerated by the graphics hardware, and some GDI+ routines may use GDI underneath. But most of GDI+ is independant of GDI.
An important, and telling, example is text rendering. In GDI+ text rendering is done completely in software; the anti-aliasing, glyph pixel-fitting and other effects is done without the video card.
(source: microsoft.com)
Microsoft's Chris Jackson had an interesting blog post where he profiled the speed difference between text rendering in GDI and GDI+:
...my GDI code path was rendering
approximately 99,000 glyphs per
second, while my GDI+ code path was
rendering approximately 16,000 glyphs
per second.
Another example is line drawing. GDI+ supports anti-aliased line/polygon and circle/ellipse drawing, while GDI does not:
(source: microsoft.com)
(source: microsoft.com)
(source: microsoft.com)
GDI+ is not COM. GDI+ has an underlying "flat" API that is callable from C (or any other language, therefore), and an object-oriented wrapper in C++ that just calls the flat API. There are also wrappers in .NET (System.Drawing) and Delphi that also just call the flat API. It works completely different from GDI in that you don't set objects (pens, brushes, fonts) to a device context, but rather pass them to drawing functions. It does not have much in common with GDI. I don't know though if the implementation of GDI+ uses GDI - but it likely doesn't, because it has so many features that are just not available in GDI.
Unfortunately, it is slower than GDI. It's very powerful though.
As decasteljau pointed out in the meantime, the performance issues might come from the fact that it is not rendered in hardware, unlike OpenVG or WPF. I recently used XNA because of that for a graphical realtime application.
Related
This might be a "homework" issue, but I think I did enough so I can get a help here.
In my assignment, we have a working OpenGL/OpenCL application. OpenGL application renders a scene and OpenCL should apply depth-of-field like effect. OpenCL part gets texture where each pixel has original color and depth and should output color for given pixel. I'm supposed to only change per-pixel function, that is part of the OpenCL.
I already have working solution using variable-size gausian filter, that samples area around calculated pixel. But it gets laggy on higher resolutions even on my dedicated NVidia graphics card. I tried optimizing out most of the redundant operations, but I haven't gotten much performance gain.
I also tried searching the web, but all algorithms I'm finding are closely tied to graphical pipeline of OpenGL or DirectX, nothing that can be used in my scenario.
Are there any algorithms, that could work in my situation?
AMD APP SDK has a sample called URNGGL (Uniform Random Noise Generator with OpenGL/OpenCL interoperability).
Have a look at https://github.com/clockfort/amd-app-sdk-fixes/tree/master/samples/opencl/cl/app/URNG.
The problem mainly is determined in the title. I tried out the Qt's example (2dpainting) and noticed, that the same code consumes more CPU power if I try to draw on QGLWidget and less if I try to draw simply on QWidget. I thought that the QGLWidget should be faster. And one more interesting phenomenon: In QGLWidget the antialiasing hint seems to be ignored.
OpenGL version: 3.3.0
So why is that?
Firstly, note this text at the bottom of the documentation that you link to:
The example shows the same painting operations performed at the same
time in a Widget and a GLWidget. The quality and speed of rendering in
the GLWidget depends on the level of support for multisampling and
hardware acceleration that your system's OpenGL driver provides. If
support for either of these is lacking, the driver may fall back on a
software renderer that may trade quality for speed.
Putting that aside, hardware rendering is not always guaranteed to be faster than software rendering; it all depends upon what the renderer is being asked to do.
An example of where software can exceed hardware is if the goal of the item being rendered is constantly changing. So, if you have a drawing program that draws a line being created by the mouse being constantly moved and it is implemented by adding points to a painter path that is drawn every frame, a hardware renderer will be subject to constant pipeline stalls as new points are added to the painter path. Setting up the graphics pipeline from a stall takes time, which is not something a software renderer has to deal with.
In the 2dPainting example you ask about, the helper class, which performs the paint calls, is doing a lot of unnecessary work; saving the painter state; setting the pen / brush; rotating the painter; restoring the brush. All of this is a bigger overhead in hardware than software. To really see hardware rendering outperform software, pre-calculating the objects' positions outside of the render loop (paint function) and then doing nothing put actually rendering in the paint function is likely to display a noticeable difference here.
Finally, regarding anti-aliasing, the documentation that you linked to states: "the QGLWidget will also use anti-aliasing if the required extensions are supported by your system's OpenGL driver"
I like GDI+ because its high performance and it's included with Windows XP. However, its blur class and effect class is only available in GDI+ 1.1, which only comes with Windows Vista or later. Despite the fact that Microsoft plans to drop support for Windows XP soon, there are still a large percentage of people who are still sticking with XP. If you make any consumer-targeted software, you have to support Windows XP. But unfortunately, GDI+ 1.1 is not redistributable under XP.
I tried a couple of opensource image libraries. However, when it comes to performance, for example, the gaussian blurring operation, they are significantly slower than gdi+.
Can anyone recommend a better alternative to GDI+ with XP support?
I'm surprised that you find the GDI+ Blur to be appealing based on it's performance.
Note that unlike it's GDI predecessor, GDI+ is not hardware accelerated (CPU-based rendering) - see this article for some details of GDI/GDI+ on XP, Vista, W7, including some basic rendering benchmarks comparing the two.
As Abdias Software mentions, the WPF BlurEffect is a good solution, as it uses DirectX for rendering.
The other option for high-performance Guassian blurring, is to implement a GPU-based blur (via a shader in some GPU-accelerated API, e.g. OpenGL/GLSL, DirectX, or Direct2D) For example: http://callumhay.blogspot.com/2010/09/gaussian-blur-shader-glsl.html
GDI+ is already sorted under Legacy graphics.
The alternative MS embraces now is Windows Presentation Foundation, or WPF for short. This is also available under XP and has better performance than GDI+.
Or as we did in the old days, write code from scratch (it isn't for everyone though). Or as an alternative you can manipulate the buffers directly by locking the bitmap and go through the byte-array to add convolutions or averaging (as used in blurring).
As a note: GDI+ do support convolutions through its Matrix class.
There is also DirectX which is more low-level and high-performing.
Personally I like/prefer GDI+ and use buffer manipulation when seen needed. I am not worried that this nor XP will go away anytime soon even when MS drop its support.
In my last question I asked whether there was a better way to rotate images than I had thought of. I ended up discovering jpegtran and have since found libjpeg-turbo.
Now I am looking for a better way to resize the images (jpegs) than imagemagick and graphicsmagick.
Is there a specialized commandline tool to resize the images in a more efficient way than imagemagick or graphicsmagick? Maybe the resizing can be done on the GPU using opencl or opengl?
The provided hardware is the same as in the other post:
Intel Atom D525 (1,8 Ghz)
Mobility Radeon HD 5430 Series
4 GB of RAM
SSD Vertility 3
Check this link out: http://leocharre.com/articles/faster-image-resizing-in-linux/
In particular the author mentions that imgresize is faster than imagemagick, and epeg is extremely fast.
epeg (http://www.systhread.net/texts/200507epeg1.php) seems quite well documented for generating thumbnails. If the quality is good enough, this could be the solution.
OpenCL is a standard for cross-platform, parallel programming of modern processors found in personal computers, servers and handheld/embedded devices. It's directly supported by ATI. You'll need to get AMD APP SDK (formerly known as AMD Stream SDK) to get GPU support (also check out this getting started guide).
Take a look at Intel's IPP - Integrated Performance Primitives. It's a multi-threaded software library of functions for multimedia and data processing applications. Among other features, it's has functions to resize images (bilinear, nearest neighbor, etc). Unfortunately, it is not free (cheapest version costs $199).
VIPS is a free image processing system. It claims that compared to most image processing libraries, VIPS needs little memory and runs quickly, especially on machines with more than one CPU. See the Speed and Memory Use page for a simple benchmark against other similar systems.
You can actually do a lot of bulk processing like this with GIMP's CLI options.
http://www.gimp.org/tutorials/Basic_Batch/
There is also djpeg and cjpeg from the Independent JPEG Group which can rescale and image to an M/N fraction. Not perfect but very fast.
Simply use FFMpeg.exe. It can resize , convert , change quality and so on.
And also it works with almost all known types of videos/audios/pictures.
It works in linux/unix too, and there is open source code for it written in C++.
You can get it Here (for Windows/compiled exe) or Here (source code and so on).
If you are developing a program, I recomend you to use standard GDIPlus library.
It does everything with pictures.
hi guys
i am in trouble with add picking object in a JOGL project.
i know that this could be done with pick buffer.. but i can't find examples
anyone?
In general, as you are probably aware, JOGL code translates directly from any other OpenGL examples you might see on the web.
GL_SELECT based picking seems to be very much out of favour these days; deprecated in the spec and poorly implemented by drivers.
Alternatives you can use are:
Rendering each object with a unique color (and all lighting / fog etc disabled) so you can determine which object the mouse is over via glReadPixels. (Clearing buffers after the picking stage so that you can then render your normal graphics). This approach is explained by the top rated answer in OpenGL GL_SELECT or manual collision detection? for example.
Ray-casting into your geometry (see the selection FAQ link below). This also means that you don't have to have an active gl context in the thread you call the code from, fwiw.
I've used both of these methods in the same application, currently having good results with the latter, but since most of the objects in that application are spheres it is a lot cheaper than it might be with arbitrary models.
http://www.opengl.org/resources/faq/technical/selection.htm