Hi i am working on some high resolution display features in which have to draw the vertical line , i am using Moveto() and lineTO() , but it is much time taking...
can anyone suggest me , what we can use instead of it ...to optimize the performance...
see the scene is , in order to draw 100 Vertical lines it is taking 84ms time, we need to reduce it to 5 ms something..
please refer me any alternate fot that.
Thanks,
Mukesh
The first step would probably be to try CDC::PolyPolyline. It's by far the easiest modification to make, and might be sufficient. Deciding on the next step after that will probably be much more difficult. The obvious possibilities would be GDI+, OpenGL, and DirectX Graphics. I've listed those in approximately increasing order of complexity to use, and likelihood that they'll give you the speed increase you want.
There is also Rectangle function that may be useful to you if those vertical lines actually make rectangles.
I don't think that 100 lines should take that long to draw. Is there something else that you aren't telling us. Are you drawing direct to a screen DC? Have you tried drawing to offscreen bitmap and then blt-ing to the screen?
I suggest you use GDI+ which should be faster, well, you need to try if it really fits your need :-)
Here is a link to integrate GDI+ with MFC: Using GDI+ with MFC or native C/C++
Related
I am working on a solar system and I wanted to have the background filled with stars. What would be the most appropriate way to accomplish this? Is using skybox better then drawing individual pixels?
Any ideas on good tutorials that would help me with either of these? It doesn't have to be realistic. Something simple would work; however I also like to try something more realistic to see how it would look.
Essentially I want a border-less, black window which I can set the location and size of./
I then want to draw a filled white polygon given four points.
I say efficient, as I am currently using OpenCV to draw which I believe is every inefficient. I want to be able to change the points and have it redraw with new points at least 30fps.
My target platform is Windows with C++.
Does anyone know the quickest way to achieve this, maybe with a small library?
I would recommend you use openGl eg via the GLUT library.
The easiest way to do this will be to use DirectX. You can create, resize, and reposition the window with the Windows API and render into it with DirectX. DX has a much more accessible API than OpenGL, because OGL is full of implicit globals and weak typing, and the support libraries like GLUT are terrible C hackery as well, whereas DX is easy to whip up RAII with a couple of custom deleters and is object-orientated.
You can also use, if on Vista or later, Direct2D, which is more designed for simple 2D rendering.
I'm trying to develop a custom set of libraries for creating GUIs in Linux, with, you know, widgets, buttons, etc. So I'm now learning to creating user interfaces using X11 and its Xlib. I get to the point of having a nice window of a size specified, at a position specified, of a specified background color, and the possibility of drawing points, rectangles, arcs. However as I drew my first circle I got really disappointed by the fact that the circle is not antialiased. I can see every single pixel as a square.
Now the question is easy. Is there any way to tell X: please antialias anything before drawing? Or do I have to avoid using XDrawArc and use a custom function which calls XDrawPoint for each point of the circle? Or there is a third solution?
Thanks in advance.
The short answer is "no". Xlib doesn't do anti-aliasing.
The longer answer is "you can use a higher level API such as Cairo Graphics". It's not necessary to roll your own.
What you encountered are the limitations of the X11 core protocol; technically it would be perfectly possible to add antialiasing to it, but that didn't happen.
Instead there's the XRender extension, that provides nice antialiased primitives. You'll also want to look into Xft to render antialiased text using vector fonts.
You can roll your own antialiasing algorithm. You have the only 2 primitives you need: 1) a function to draw TrueColor points (namely, xcb_poly_point(), if you're using XCB), and 2) for loops.
I am learning opengl es and am planning to make a program which will have a shape which can be cut into a smaller shape by removing a part of the shape dynamicly. The constraint is I must be able to tell if an object is inside or outside the cut shape.
The option I thought of are:
1) use a stencil buffer made up of just a black and white mask. This way I can also use the same map for collision detection.
2) the other option is to dynamicly change my mind renderd primitive an then tesselating it. This sounds more complex and is currently my least favorite option. It would also make the collision detection more difficult.
PS
I would like the part of the shape removed to be fall of in animation, I am not sure how choosing any of these methods will affect the ease of doing so. Please express your opinion.
What are your thoughts on this?
Keep in mind that I am new to opengl an might be making mistakes without realizing it.
Thanks, Jason
It is generally considered a good idea to issue only write-commands to the graphics card. Basically that is "dont use glGet* commands at all", because the latency of those commands might be somewhat high.
That said option 1) is great if you just want to mask out stuff. As you are trying to make the cut part fall off this is really not an option, as you have to retrieve/reconstruct the vertices of that part.
I don't quite get the "tesselation" part of your second option, but if your primitive is a polygon and your cuts are straight lines, it is easy to calculate the 2 polygons after the cut. In fact the viewport clipping routine in OpenGL does that all the time and there is a lot of literatur, for example http://en.wikipedia.org/wiki/Sutherland-Hodgman
In the long term it is often way better to first build a (non-visual) model of what is going on in the application before visualizing.
What is the ideal method for blinking information on a display to draw attention to an error condition in some data in a natural fashion.
Should the blink be all on / all off, or should there be an aspect of fast ramp up and down of brightness instead of instant on / off transitions?
Should the blink be equally on and off, or should it be something like 60% time on alternating with 40% time off?
What is the most natural frequency? How many blinks per second?
The goal is to draw attention to the error in some data, but to look natural and ascetically pleasing.
Hopefully, the solution is not to hard to implement using Qt and C++.
I've always found the highlight effect present in various javascript libraries pleasing. It basically flashes the background of the object a bright-ish yellow immediately, then fades back to the original background color.
Blinking may cause various health problems. Make sure to take a look at this IBM article
I don't think blinking is used much anymore. I personally think it detracts from the attention it's intending on receiving. When I try to focus on the 'important' information that is blinking, the blinking impedes me from actually reading it and focusing on it. If anything is going to blink, perhaps it'd be best to have a border that's blinking, if at all.
Just my opinion, not trying to present it as a fact.
EDIT: Like Adam said, the highlight effect is much nicer, in my opinion. It gets the viewer's attention and then actually lets them do the reading.
Blinking definitely causes readability problems as #Blaenk pointed out. If you must blink, I suggest a long period between blinks: hide for.5 seconds, show for 5 seconds..
Highlighting is definitely more pleasing; however, if the user isn't looking at the screen or that portion of the screen before it fades to the normal color, it may be missed altogether. I would suggest either a very slow/delayed fade, or not fading at all. There's nothing wrong with a static highlight.
For prettiness, I'd use a sinusoidal blink, where the intensity of the "blink" color is varied by a sin wave with a period of about 2 seconds. However, this is much harder to implement than a simple on/off blink, since you'd need to achieve a high frame rate to make the effect appear smooth.
Alternatively, I'm starting to see more and more Flash/Silverlight apps that draw attention through a combination of highlighting followed by a temporary animation of the text growing (increasing font size) followed by decreasing font size back to normal. Do this once, with decent timing and it's enough to draw attention without being too annoying.