Its been a few years (20+) since I had to do this, but I seem to remember the best way to acheive this was to use the standard Bresenham algorithm, but to just set more than one pixel at each point. Basically for a three pixel wide line, set the 8 pixels around each point as well as the point itself... Some optimisation is possible.
I have an application that displays (large 2500X3000) 12-bit grayscale images within an image control. I am using the Gray16 pixel format and I am scaling the data to 16 bits by simple bit-shifting. Images have low contrast, so I implemented functionality to adjust brightness and contrast. The functionality was based on setting the image's Effect to a pixel shader that accepts brightness and contrast parameters. Obviously, this implementation is very efficient and avoids moving large amount of data around in memory.
When adjusting the contrast to a high setting, the displayed image exhibits unacceptable contouring, as though the bit-depth of the image has been reduced to 5 or 6. As a baseline test, I implemented the same functionality without a pixel shader - I applied the contrast and brightness settings to the image, reduced the bit-depth to 8 bits and displayed the image with the Gray8 pixel format (one that I have a great deal of familiarity with). The latter implementation showed little to no contouring.
Does anyone know why applying a pixel shader would reduce the apparent bit-depth of an image? Does the pixel shader HLSL code work on reduced bit-depth data, e.g. eight or less, that is a function of the hardware/drivers or the OS?
All data in the pixel shader are floats that are scaled from 0 to 1, so you haven't any idea of the quantization level (at least to my knowledge)
Hum. My shader knowledge is limited but if anything I thought it'd be higher (I seem to recall some modern cards being able to do 64bit floats).
You possibly have to turn it on (or off) since working with fixed points is inherently faster. For this application I sense that speed is not your issue.
Thank you! I did read through that and I noted that it was a container in a container housing another container. I was trying to avoid adding one more container to the list if possible but if you think that's a good route, then I'm buying it!
I've got a working datagridview housed in a toolstrip though a host. It's resizeable, and rounded, and those pesky little rectangle corners show up if the background is changed...yuk!
Is it possible to draw a hexagon with children and paint it with Lineargradientbrush? If it is possible, can somebody help me with the sample?
Example is the type used in Microsoft office 2007 color dialog box.
I googled it as you directed and I got good one but it is written in C++ and I am not familiar with C++. This is the link (www.codeproject.com/Articles/24970/XColorDialog-MFC-color-picker-control-that-disp). Can you help in converting it to VB.NET or C#? Or can you build the DLL in the same language?
I am aware of that but remember that 2 good heads are better than one. Well, you advice is very ok. You learn better when you do thing yourself but other persons' idea can pave you way. Your contributions on how to do it is also impotant.
Hi, I'm trying to render the contents of a window, with desktop composition disabled, on an off-screen buffer. I have no control over the window and the only thing I have is the window handle and the DC. I thought about allocating an off-screen DC and doing something like:
/* The window handle is stored in the
hWnd variable and the offscreen DC,
is in hDC */
PostMessage(hWnd, WM_PAINT, 0, 0);
But it doesn't seem to work. Please note that I don't want the application to render on the primary display DC. In other words I want to redirect it's graphical output, and blit the result in my window.
modified 16-Jun-12 9:59am.
Last Visit: 31-Dec-99 18:00 Last Update: 26-Apr-17 7:03