Search Results

Search found 126 results on 6 pages for 'hdc'.

Page 1/6 | 1 2 3 4 5 6  | Next Page >

  • Does HDC use alpha channel?

    - by Crend King
    Hello. Is there a way I can determine if an HDC uses alpha channel? I read Question 333559 and Question 685684, but their questions are about BITMAP. Apparently, some HDC has alpha channel (though they may not use it. Call this "Type 1") while others do not ("Type 2"). I know this by doing the following: Given a HDC, Create a compatible DC, and create a DIB section. Select the created HBITMAP into the compatible DC. BitBlt the source HDC to the compatible DC. Now examine the DIB section bits. For type 2 HDC, after every 3 bytes there is a byte always 0 (like 255 255 255 0); for type 1, these bytes are usualy 255 (like 250 240 230 255). To avoid false positive, I memset the bits to all 0x80 prior to the calls. Use GetDIBits directly on the source HDC, specify the HBITMAP as GetCurrentObject(hdc, OBJ_BITMAP). For both types of HDC, the 4th bytes are always 0. Change the DC bitmap by calling ExtTextOut. For type 2, ExtTextOut always set the 4th bytes to 0. For type 1, ExtTextOut always leave them untouched. I also noticed that the source HDC that are created by APIs (CreateCompatibleDC(), BeginPaint() ...) are always type 2. Type 1 HDC are from standard controls (like menu text). Even the HDC I CreateCompatibleDC from a type 1 becomes a type 2. So, on one hand, I'm frustrated that Microsoft does not provide equal information to developers (another example may be that you cannot know the direction of a HBITMAP after it is created), on the other hand, I'm still wondering is there a way to distinguish these HDC. Thanks for help.

    Read the article

  • Sharing HDC between different processes

    - by Heinrich Ulbricht
    Hi, I am writing some kind of IPC functionality and need to pass certain resources from one process to another. This works well for Pipe handles etc. which can be duplicated via DuplicateHandle. Now I need to pass a HDC from one process to the other. Is this even possible? If yes: how? Sub-Question: I am assuming passing window handles (HWND) from one process to the other is safe. Is this assumption correct? Thanks for your help!

    Read the article

  • Transparency and AlphaBlending

    - by TechTwaddle
    In this post we'll look at the AlphaBlend() api and how it can be used for semi-transparent blitting. AlphaBlend() takes a source device context and a destination device context (DC) and combines the bits in such a way that it gives a transparent effect. Follow the links for the msdn documentation. So lets take a image like, and AlphaBlend() it on our window. The code to do so is below, (under the WM_PAINT message of WndProc) HBITMAP hBitmap=NULL, hBitmapOld=NULL; HDC hMemDC=NULL; BLENDFUNCTION bf; hdc = BeginPaint(hWnd, &ps); hMemDC = CreateCompatibleDC(hdc); hBitmap = LoadBitmap(g_hInst, MAKEINTRESOURCE(IDB_BITMAP1)); hBitmapOld = SelectObject(hMemDC, hBitmap); bf.BlendOp = AC_SRC_OVER; bf.BlendFlags = 0; bf.SourceConstantAlpha = 80; //transparency value between 0-255 bf.AlphaFormat = 0;    AlphaBlend(hdc, 0, 25, 240, 100, hMemDC, 0, 0, 240, 100, bf); SelectObject(hMemDC, hBitmapOld); DeleteDC(hMemDC); DeleteObject(hBitmap); EndPaint(hWnd, &ps);   The code above creates a memory DC (hMemDC) using CreateCompatibleDC(), loads a bitmap onto the memory DC and AlphaBlends it on the device DC (hdc), with a transparency value of 80. The result is: Pretty simple till now. Now lets try to do something a little more exciting. Lets get two images involved, each overlapping the other, giving a better demonstration of transparency. I am also going to add a few buttons so that the user can increase or decrease the transparency by clicking on the buttons. Since this is the first time I played around with GDI apis, I ran into something that everybody runs into sometime or the other, flickering. When clicking the buttons the images would flicker a lot, I figured out why and used something called double buffering to avoid flickering. We will look at both my first implementation and the second implementation just to give the concept a little more depth and perspective. A few pre-conditions before I dive into the code: - hBitmap and hBitmap2 are handles to the two images obtained using LoadBitmap(), these variables are global and are initialized under WM_CREATE - The two buttons in the application are labeled Opaque++ (make more opaque, less transparent) and Opaque-- (make less opaque, more transparent) - DrawPics(HWND hWnd, int step=0); is the function called to draw the images on the screen. This is called from under WM_PAINT and also when the buttons are clicked. When Opaque++ is clicked the 'step' value passed to DrawPics() is +20 and when Opaque-- is clicked the 'step' value is -20. The default value of 'step' is 0 Now lets take a look at my first implementation: //this funciton causes flicker, cos it draws directly to screen several times void DrawPics(HWND hWnd, int step) {     HDC hdc=NULL, hMemDC=NULL;     BLENDFUNCTION bf;     static UINT32 transparency = 100;     //no point in drawing when transparency is 0 and user clicks Opaque--     if (transparency == 0 && step < 0)         return;     //no point in drawing when transparency is 240 (opaque) and user clicks Opaque++     if (transparency == 240 && step > 0)         return;         hdc = GetDC(hWnd);     if (!hdc)         return;     //create a memory DC     hMemDC = CreateCompatibleDC(hdc);     if (!hMemDC)     {         ReleaseDC(hWnd, hdc);         return;     }     //while increasing transparency, clear the contents of screen     if (step < 0)     {         RECT rect = {0, 0, 240, 200};         FillRect(hdc, &rect, (HBRUSH)GetStockObject(WHITE_BRUSH));     }     SelectObject(hMemDC, hBitmap2);     BitBlt(hdc, 0, 25, 240, 100, hMemDC, 0, 0, SRCCOPY);         SelectObject(hMemDC, hBitmap);     transparency += step;     if (transparency >= 240)         transparency = 240;     if (transparency <= 0)         transparency = 0;     bf.BlendOp = AC_SRC_OVER;     bf.BlendFlags = 0;     bf.SourceConstantAlpha = transparency;     bf.AlphaFormat = 0;            AlphaBlend(hdc, 0, 75, 240, 100, hMemDC, 0, 0, 240, 100, bf);     DeleteDC(hMemDC);     ReleaseDC(hWnd, hdc); }   In the code above, we first get the window DC using GetDC() and create a memory DC using CreateCompatibleDC(). Then we select hBitmap2 onto the memory DC and Blt it on the window DC (hdc). Next, we select the other image, hBitmap, onto memory DC and AlphaBlend() it over window DC. As I told you before, this implementation causes flickering because it draws directly on the screen (hdc) several times. The video below shows what happens when the buttons were clicked rapidly: Well, the video recording tool I use captures only 15 frames per second and so the flickering is not visible in the video. So you're gonna have to trust me on this, it flickers (; To solve this problem we make sure that the drawing to the screen happens only once and to do that we create an additional memory DC, hTempDC. We perform all our drawing on this memory DC and finally when it is ready we Blt hTempDC on hdc, and the images are displayed in one go. Here is the code for our new DrawPics() function: //no flicker void DrawPics(HWND hWnd, int step) {     HDC hdc=NULL, hMemDC=NULL, hTempDC=NULL;     BLENDFUNCTION bf;     HBITMAP hBitmapTemp=NULL, hBitmapOld=NULL;     static UINT32 transparency = 100;     //no point in drawing when transparency is 0 and user clicks Opaque--     if (transparency == 0 && step < 0)         return;     //no point in drawing when transparency is 240 (opaque) and user clicks Opaque++     if (transparency == 240 && step > 0)         return;         hdc = GetDC(hWnd);     if (!hdc)         return;     hMemDC = CreateCompatibleDC(hdc);     hTempDC = CreateCompatibleDC(hdc);     hBitmapTemp = CreateCompatibleBitmap(hdc, 240, 150);     hBitmapOld = (HBITMAP)SelectObject(hTempDC, hBitmapTemp);     if (!hMemDC)     {         ReleaseDC(hWnd, hdc);         return;     }     //while increasing transparency, clear the contents     if (step < 0)     {         RECT rect = {0, 0, 240, 150};         FillRect(hTempDC, &rect, (HBRUSH)GetStockObject(WHITE_BRUSH));     }     SelectObject(hMemDC, hBitmap2);     //Blt hBitmap2 directly to hTempDC     BitBlt(hTempDC, 0, 0, 240, 100, hMemDC, 0, 0, SRCCOPY);         SelectObject(hMemDC, hBitmap);     transparency += step;     if (transparency >= 240)         transparency = 240;     if (transparency <= 0)         transparency = 0;     bf.BlendOp = AC_SRC_OVER;     bf.BlendFlags = 0;     bf.SourceConstantAlpha = transparency;     bf.AlphaFormat = 0;            AlphaBlend(hTempDC, 0, 50, 240, 100, hMemDC, 0, 0, 240, 100, bf);     //now hTempDC is ready, blt it directly on hdc     BitBlt(hdc, 0, 25, 240, 150, hTempDC, 0, 0, SRCCOPY);     SelectObject(hTempDC, hBitmapOld);     DeleteObject(hBitmapTemp);     DeleteDC(hMemDC);     DeleteDC(hTempDC);     ReleaseDC(hWnd, hdc); }   This function is very similar to the first version, except for the use of hTempDC. Another point to note is the use of CreateCompatibleBitmap(). When a memory device context is created using CreateCompatibleDC(), the context is exactly one monochrome pixel high and one monochrome pixel wide. So in order for us to draw anything onto hTempDC, we first have to set a bitmap on it. We use CreateCompatibleBitmap() to create a bitmap of required dimension (240x150 above), and then select this bitmap onto hTempDC. Think of it as utilizing an extra canvas, drawing everything on the canvas and finally transferring the contents to the display in one scoop. And with this version the flickering is gone, video follows:   If you want the entire solutions source code then leave a message, I will share the code over SkyDrive.

    Read the article

  • Win32 and Win64 programming in C sources?

    - by Nick Rosencrantz
    I'm learning OpenGL with C and that makes me include the windows.h file in my project. I'd like to look at some more specific windows functions and I wonder if you can cite some good sources for learning the basics of Win32 and Win64 programming in C (or C++). I use MS Visual C++ and I prefer to stick with C even though much of the Windows API seems to be C++. I'd like my program to be portable and using some platform-indepedent graphics library like OpenGL I could make my program portable with some slight changes for window management. Could you direct me with some pointers to books or www links where I can find more info? I've already studied the OpenGL red book and the C programming language, what I'm looking for is the platform-dependent stuff and how to handle that since I run both Linux and Windows where I find the development environment Visual Studio is pretty good but the debugger gdb is not available on windows so it's a trade off which environment i'll choose in the end - Linux with gcc or Windows with MSVC. Here is the program that draws a graphics primitive with some use of windows.h This program is also runnable on Linux without changing the code that actually draws the graphics primitive: #include <windows.h> #include <gl/gl.h> LRESULT CALLBACK WindowProc(HWND, UINT, WPARAM, LPARAM); void EnableOpenGL(HWND hwnd, HDC*, HGLRC*); void DisableOpenGL(HWND, HDC, HGLRC); int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { WNDCLASSEX wcex; HWND hwnd; HDC hDC; HGLRC hRC; MSG msg; BOOL bQuit = FALSE; float theta = 0.0f; /* register window class */ wcex.cbSize = sizeof(WNDCLASSEX); wcex.style = CS_OWNDC; wcex.lpfnWndProc = WindowProc; wcex.cbClsExtra = 0; wcex.cbWndExtra = 0; wcex.hInstance = hInstance; wcex.hIcon = LoadIcon(NULL, IDI_APPLICATION); wcex.hCursor = LoadCursor(NULL, IDC_ARROW); wcex.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH); wcex.lpszMenuName = NULL; wcex.lpszClassName = "GLSample"; wcex.hIconSm = LoadIcon(NULL, IDI_APPLICATION);; if (!RegisterClassEx(&wcex)) return 0; /* create main window */ hwnd = CreateWindowEx(0, "GLSample", "OpenGL Sample", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 256, 256, NULL, NULL, hInstance, NULL); ShowWindow(hwnd, nCmdShow); /* enable OpenGL for the window */ EnableOpenGL(hwnd, &hDC, &hRC); /* program main loop */ while (!bQuit) { /* check for messages */ if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { /* handle or dispatch messages */ if (msg.message == WM_QUIT) { bQuit = TRUE; } else { TranslateMessage(&msg); DispatchMessage(&msg); } } else { /* OpenGL animation code goes here */ glClearColor(0.0f, 0.0f, 0.0f, 0.0f); glClear(GL_COLOR_BUFFER_BIT); glPushMatrix(); glRotatef(theta, 0.0f, 0.0f, 1.0f); glBegin(GL_TRIANGLES); glColor3f(1.0f, 0.0f, 0.0f); glVertex2f(0.0f, 1.0f); glColor3f(0.0f, 1.0f, 0.0f); glVertex2f(0.87f, -0.5f); glColor3f(0.0f, 0.0f, 1.0f); glVertex2f(-0.87f, -0.5f); glEnd(); glPopMatrix(); SwapBuffers(hDC); theta += 1.0f; Sleep (1); } } /* shutdown OpenGL */ DisableOpenGL(hwnd, hDC, hRC); /* destroy the window explicitly */ DestroyWindow(hwnd); return msg.wParam; } LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { switch (uMsg) { case WM_CLOSE: PostQuitMessage(0); break; case WM_DESTROY: return 0; case WM_KEYDOWN: { switch (wParam) { case VK_ESCAPE: PostQuitMessage(0); break; } } break; default: return DefWindowProc(hwnd, uMsg, wParam, lParam); } return 0; } void EnableOpenGL(HWND hwnd, HDC* hDC, HGLRC* hRC) { PIXELFORMATDESCRIPTOR pfd; int iFormat; /* get the device context (DC) */ *hDC = GetDC(hwnd); /* set the pixel format for the DC */ ZeroMemory(&pfd, sizeof(pfd)); pfd.nSize = sizeof(pfd); pfd.nVersion = 1; pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER; pfd.iPixelType = PFD_TYPE_RGBA; pfd.cColorBits = 24; pfd.cDepthBits = 16; pfd.iLayerType = PFD_MAIN_PLANE; iFormat = ChoosePixelFormat(*hDC, &pfd); SetPixelFormat(*hDC, iFormat, &pfd); /* create and enable the render context (RC) */ *hRC = wglCreateContext(*hDC); wglMakeCurrent(*hDC, *hRC); } void DisableOpenGL (HWND hwnd, HDC hDC, HGLRC hRC) { wglMakeCurrent(NULL, NULL); wglDeleteContext(hRC); ReleaseDC(hwnd, hDC); }

    Read the article

  • Gradient fill bitmap and CreatePatternBrush just gives black fill instead of gradient

    - by mtopley
    I'm trying to create a Gradient Brush in windows mobile as follows: HBITMAP hBitmap = CreateBitmap(16, 16, 1, 16, NULL); HDC hDC = CreateCompatibleDC(NULL); HBITMAP hPrevious = SelectObject(hDC,hBitmap); TRIVERTEX vert[2]; GRADIENT_RECT gRect; ... fill in vert and gRect GradientFill(hDC, vert, 2,&gRect, 1, Direction); SelectObject(hDC, hPrevious); Delete(hDC); HBRUSH hPatternBrush = CreatePatternBrush(hBitmap); HDC hDC = BeginPaint(hWnd, &ps); SelectObject(hDC, hPatternBrush); RoundRect(hDC, ...); EndPaint(hWND, &ps); This code create a round rect with a black background, not the pattern brush. I can draw the hBitmap which is used to create the brush and it draws the gradient. Anyone got a solution?

    Read the article

  • BitBlting multiple images to buffer

    - by Anonymous
    So I've made a class which draws a transparant image to a buffer. the buffer is a HDC which has been used blackness on. What I am trying to do is draw three images to this buffer. Which means I am using this function three times. After that's done, I output it to the screen (using SRCCOPYing the buffer). But what I get to see is just the third image and blackness. void draw_buffer(HDC buffer, int draw_x, int draw_y) { BitBlt(this-main, draw_x, draw_y, this-img_width, this-img_height, this-image, this-mask_x, this-mask_y, SRCAND); BitBlt(this-main, draw_x, draw_y, this-img_width, this-img_height, this-image, this-img_x, this-img_y, SRCPAINT); BitBlt(buffer, 0, 0, 800, 600, this-main, 0, 0, SRCCOPY); } At initiation, this-main becomes this: this->main = CreateCompatibleDC(GetDC(0)); this->bitmap = CreateCompatibleBitmap(GetDC(0),800,600); SelectObject(this->main, this->bitmap); What is wrong with my code?

    Read the article

  • How to resize an openGL window created with wglCreateContext?

    - by Nick
    Is it possible to resize an openGL window (or device context) created with wglCreateContext without disabling it? If so how? Right now I have a function which resizes the DC but the only way I could get it to work was to call DisableOpenGL and then re-enable. This causes any textures and other state changes to be lost. I would like to do this without the disable so that I do not have to go through the tedious task of recreating the openGL DC state. HWND hWnd; HDC hDC; void View_setSizeWin32(int width, int height) { // resize the window LPRECT rec = malloc(sizeof(RECT)); GetWindowRect(hWnd, rec); SetWindowPos( hWnd, HWND_TOP, rec->left, rec->top, rec->left+width, rec->left+height, SWP_NOMOVE ); free(rec); // sad panda DisableOpenGL( hWnd, hDC, hRC ); EnableOpenGL( hWnd, &hDC, &hRC ); glMatrixMode(GL_PROJECTION); glLoadIdentity(); glOrtho(-(width/2), width/2, -(height/2), height/2, -1.0, 1.0); // have fun recreating the openGL state.... } void EnableOpenGL(HWND hWnd, HDC * hDC, HGLRC * hRC) { PIXELFORMATDESCRIPTOR pfd; int format; // get the device context (DC) *hDC = GetDC( hWnd ); // set the pixel format for the DC ZeroMemory( &pfd, sizeof( pfd ) ); pfd.nSize = sizeof( pfd ); pfd.nVersion = 1; pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER; pfd.iPixelType = PFD_TYPE_RGBA; pfd.cColorBits = 24; pfd.cDepthBits = 16; pfd.iLayerType = PFD_MAIN_PLANE; format = ChoosePixelFormat( *hDC, &pfd ); SetPixelFormat( *hDC, format, &pfd ); // create and enable the render context (RC) *hRC = wglCreateContext( *hDC ); wglMakeCurrent( *hDC, *hRC ); } void DisableOpenGL(HWND hWnd, HDC hDC, HGLRC hRC) { wglMakeCurrent( NULL, NULL ); wglDeleteContext( hRC ); ReleaseDC( hWnd, hDC ); }

    Read the article

  • Windows API Programing....

    - by vs4vijay
    Hello There... Its me Vijay.. I m Trying to make a CrossHair(some kind of cursor) On The Screen while running a Game (Counter Strike)... so i did this... ############################# #include<iostream.h> #include<windows.h> #include<conio.h> #include<dos.h> #include<stdlib.h> #include<process.h> #include <time.h> int main() { HANDLE hl = OpenProcess(PROCESS_ALL_ACCESS,TRUE,pid); // Here pid is the process ID of the Game... HDC hDC = GetDC(NULL); //Here i pass NULL for Entire Screen... HBRUSH hb=CreateSolidBrush(RGB(0,255,255)); SelectObject(hDC,hb); POINT p; while(!kbhit()) { int x=1360/2,y=768/2; MoveToEx(hDC,x-20,y,&p); LineTo(hDC,x+20,y); SetPixel(hDC,x,y,RGB(255,0,0)); SetPixel(hDC,x-1,y-1,RGB(255,0,0)); SetPixel(hDC,x-1,y+1,RGB(255,0,0)); SetPixel(hDC,x+1,y+1,RGB(255,0,0)); SetPixel(hDC,x+1,y-1,RGB(255,0,0)); MoveToEx(hDC,x,y-20,&p); LineTo(hDC,x,y+20); } cin.get(); return 0; } #################################### it works fine....at desktop i see crosshair...but my problem is that when i run game...the cross here got disappeared.... so i think i did not handle the process of game... so i pass the HANDLE to the GetDC(hl)... But GetDC take only HWND(Handle To Window)... so i typecast it like this... HWND hl = (HWND)OpenProcess(PROCESS_ALL_ACCESS,TRUE,pid); and passed hl to the GetDC(hl)... but it doesnt work...Whats wrong with the code... plz tell me how do i make a simple shape at the screen on a process or game... PS : (My Compiler Is DevCPP and OS WinXP SP3....)

    Read the article

  • GDI+ double buffering in C++

    - by David Titarenco
    I haven't written anything with GDI for a while now (and never with GDI+), and I'm just working on a fun project, but for the life of me, I can't figure out how to double buffer GDI+ void DrawStuff(HWND hWnd) { HDC hdc; HDC hdcBuffer; PAINTSTRUCT ps; hdc = BeginPaint(hWnd, &ps); hdcBuffer = CreateCompatibleDC(hdc); Graphics graphics(hdc); graphics.Clear(Color::Black); // drawing stuff, i.e. bunnies: Image bunny(L"bunny.gif"); graphics.DrawImage(&bunny, 0, 0, bunny.GetWidth(), bunny.GetHeight()); BitBlt(hdc, 0,0, WIDTH , HEIGHT, hdcBuffer, 0,0, SRCCOPY); EndPaint(hWnd, &ps); } The above works (everything renders perfectly), but it flickers. If I change Graphics graphics(hdc); to Graphics graphics(hdcBuffer);, I see nothing (although I should be bitblt'ing the buffer-hWnd hdc at the bottom). My message pipeline is set up properly (WM_PAINT calls DrawStuff), and I'm forcing a WM_PAINT message every program loop by calling RedrawWindow(window, NULL, NULL, RDW_ERASE | RDW_INVALIDATE | RDW_UPDATENOW); I'm probably going about the wrong way to do this, any ideas? The MSDN documentation is cryptic at best.

    Read the article

  • WIn API Basic Paint program

    - by Tom Burman
    Just trying to learn a bit of Win API. Im trying to make a basic drawing app, a bit like MS Paint. For the time being im trying to get one function to work which is, when you left click and drag the mouse around the screen a line is drawn behind the mouse. Heres what i have so far, but for some reason: 1) the line starts drawing straight away rather then waiting for the left click 2) the line isn't solid its very dotty. case WM_MOUSEMOVE: { if(MK_LBUTTON){ hdc = GetDC(hwnd); hPen = CreatePen(PS_SOLID,5,RGB(0, 0, 255)); SelectObject(hdc, hPen); int x = LOWORD(lParam); int y = HIWORD(lParam); MoveToEx(hdc,x,y,NULL); LineTo(hdc, LOWORD(lParam), HIWORD(lParam)); ReleaseDC(hwnd,hdc); } else break; } } Thanks for any help!

    Read the article

  • How to obtain the correct physical size of the monitor?

    - by KindDragon
    How can I get the size of the display in centimeters or inches? This code does not always works correctly: HDC hdc = CreateDC(_T("DISPLAY"),dd.DeviceName,NULL,NULL); int width = GetDeviceCaps(hdc, HORZSIZE); int height = GetDeviceCaps(hdc, VERTSIZE); ReleaseDC(0, hdc) Especially for multi-monitor configuration. Update: I need to get the size just for ordinary monitors, which have a constant physical size.

    Read the article

  • Strange error with CreateCompatibleDC

    - by sevaxx
    Maybe this is a foolish question, I can't see why I can not get a DC created in the following code : HBITMAP COcrDlg::LoadClippedBitmap(LPCTSTR pathName,UINT maxWidth,UINT maxHeight) { HBITMAP hBmp = (HBITMAP)::LoadImage(NULL, pathName, IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_CREATEDIBSECTION); if (!hBmp) return NULL; HDC hdc = (HDC)GetDC(); HDC hdcMem = CreateCompatibleDC(hdc); if (!hdcMem) { DWORD err = GetLastError(); } ... ... ... The bitmap hBmp is loaded fine and hdc has a valid value. But the call to CreateCompatibleDC() returns a NULL pointer. Then, GetLastError() returns 0 ! Anybody can guess what's going on here , please ? PS : There are no memory allocations or GDI routines called before this one...so I think memory leaks should be ruled out.

    Read the article

  • c++, win 32 , Erase text using TextOut or DrawText [on hold]

    - by XXXXX
    How to erase the inputted character on the window and to write the another one on its place??? Say, for example, d d d d was inputted, I want to redraw it to d j j f I'm trying to do this in the following way: TextOut(hdc,rect.right,rect.top,(LPCWSTR)" ",2); DrawText( hdc, (LPCWSTR)str, -1, &rect, DT_SINGLELINE | DT_NOCLIP ) ; or DrawText( hdc, (LPCWSTR)" ", -1, &rect, DT_SINGLELINE | DT_NOCLIP ) ; DrawText( hdc, (LPCWSTR)str, -1, &rect, DT_SINGLELINE | DT_NOCLIP ) ; Anyway, some characters are redrawn, and in some cases(f, j,i characters) the junks are seen(one character is just drawn on another). I haven't set the SetBkMode to transparent. What to do? Thanks much in advance!!!

    Read the article

  • Modern OpenGL context failure [migrated]

    - by user209347
    OK, I managed to create an OpenGL context with wglcreatecontextattribARB with version 3.2 in my attrib struct (So I have initialized a 3.2 opengl context). It works, but the strange thing is, when I use glBindBuffer e,g. I still get unreferenced linker error, shouldn't a newer context prevent this? I'm on windows BTW, Linux doesn't have to deal with older and newer contexts (it directly supports the core of its version). The code: PIXELFORMATDESCRIPTOR pfd; HGLRC tmpRC; int iFormat; if (!(hDC = GetDC(hWnd))) { CMsgBox("Unable to create a device context. Program will now close.", "Error"); return false; } ZeroMemory(&pfd, sizeof(pfd)); pfd.nSize = sizeof(pfd); pfd.nVersion = 1; pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER; pfd.iPixelType = PFD_TYPE_RGBA; pfd.cColorBits = attribs->colorbits; pfd.cDepthBits = attribs->depthbits; pfd.iLayerType = PFD_MAIN_PLANE; if (!(iFormat = ChoosePixelFormat(hDC, &pfd))) { CMsgBox("Unable to find a suitable pixel format. Program will now close.", "Error"); return false; } if (!SetPixelFormat(hDC, iFormat, &pfd)) { CMsgBox("Unable to initialize the pixel formats. Program will now close.", "Error"); return false; } if (!(tmpRC=wglCreateContext(hDC))) { CMsgBox("Unable to create a rendering context. Program will now close.", "Error"); return false; } if (!wglMakeCurrent(hDC, tmpRC)) { CMsgBox("Unable to activate the rendering context. Program will now close.", "Error"); return false; } strncpy(vers, (char*)glGetString(GL_VERSION), 3); vers[3] = '\0'; if (sscanf(vers, "%i.%i", &glv, &glsubv) != 2) { CMsgBox("Unable to retrieve the OpenGL version. Program will now close.", "Error"); return false; } hRC = NULL; if (glv > 2) // Have OpenGL 3.+ support { if ((wglCreateContextAttribsARB = (PFNWGLCREATECONTEXTATTRIBSARBPROC)wglGetProcAddress("wglCreateContextAttribsARB"))) { int attribs[] = {WGL_CONTEXT_MAJOR_VERSION_ARB, glv, WGL_CONTEXT_MINOR_VERSION_ARB, glsubv,WGL_CONTEXT_FLAGS_ARB, 0,0}; hRC = wglCreateContextAttribsARB(hDC, 0, attribs); wglMakeCurrent(NULL, NULL); wglDeleteContext(tmpRC); if (!wglMakeCurrent(hDC, hRC)) { CMsgBox("Unable to activate the rendering context. Program will now close.", "Error"); return false; } moderncontext = true; } } if (hRC == NULL) { hRC = tmpRC; moderncontext = false; }

    Read the article

  • GDI RoundRect on Compact Framework: make rounded rectangle's outside transparent.

    - by VansFannel
    Hello! I'm using the RoundRect GDI function to draw a rounded rectangle following this example: .NET CF Custom Control: RoundedGroupBox Because all controls are square, it also draw the corners outside of the rounded rectangle. How can I make this space left outside the rectangle transparent? The OnPaint method is: protected override void OnPaint(PaintEventArgs e) { int outerBrushColor = HelperMethods.ColorToWin32(m_outerColor); int innerBrushColor = HelperMethods.ColorToWin32(this.BackColor); IntPtr hdc = e.Graphics.GetHdc(); try { IntPtr hbrOuter = NativeMethods.CreateSolidBrush(outerBrushColor); IntPtr hOldBrush = NativeMethods.SelectObject(hdc, hbrOuter); NativeMethods.RoundRect(hdc, 0, 0, this.Width, this.Height, m_diametro, m_diametro); IntPtr hbrInner = NativeMethods.CreateSolidBrush(innerBrushColor); NativeMethods.SelectObject(hdc, hbrInner); NativeMethods.RoundRect(hdc, 0, 18, this.Width, this.Height, m_diametro, m_diametro); NativeMethods.SelectObject(hdc, hOldBrush); NativeMethods.DeleteObject(hbrOuter); NativeMethods.DeleteObject(hbrInner); } finally { e.Graphics.ReleaseHdc(hdc); } if (!string.IsNullOrEmpty(m_roundedGroupBoxText)) { Font titleFont = new Font("Tahoma", 9.0F, FontStyle.Bold); Brush titleBrush = new SolidBrush(this.BackColor); try { e.Graphics.DrawString(m_roundedGroupBoxText, titleFont, titleBrush, 14.0F, 2.0F); } finally { titleFont.Dispose(); titleBrush.Dispose(); } } base.OnPaint(e); } An the OnPaintBackground is: protected override void OnPaintBackground(PaintEventArgs e) { if (this.Parent != null) { SolidBrush backBrush = new SolidBrush(this.Parent.BackColor); try { e.Graphics.FillRectangle(backBrush, 0, 0, this.Width, this.Height); } finally { backBrush.Dispose(); } } } Thank you!

    Read the article

  • MS Detours Library, detouring non win api function

    - by flavour404
    Hi, I want to use the windows detours library to detour a non win api function. The function is part of the Qt library (QtGui4.dll). I am wondering how I would set up the function signature for : void QPainter::drawText ( const QPointF & position, const QString & text ) I had a go with this and it received my usual share of errors, a little explanation of requirements would be interesting as well: void (QPainter * real_drawText)(const QPointF & position, const QString & text) = drawText This is what they look like for TextOut, under the windows API: BOOL (WINAPI * Real_TextOut)(HDC a0, int a1, int a2, LPCWSTR a3, int a4) = TextOutW; BOOL WINAPI Mine_TextOut(HDC hdc,int X,int Y,LPCWSTR text,int textLen) { BOOL rv = Real_TextOut(hdc, X, Y, text, textLen); HWND hWindow = WindowFromDC(hdc); SendTextMessage(hWindow, text); return rv; } Thanks.

    Read the article

  • How can I draw a hollow rectangle using CreatePen?

    - by LarsTech
    Since using the DrawArc function in GDI+ isn't very accurate when drawing a small rounded rectangle, I am using RoundRect instead. Protected Overrides Sub OnPaint(ByVal e As PaintEventArgs) Dim hDC As IntPtr = e.Graphics.GetHdc Dim rc As New Rectangle(10, 10, 64, 24) Dim hPen As IntPtr = Win32.CreatePen(Win32.PenStyle.PS_SOLID, 0, _ ColorTranslator.ToWin32(Color.Green)) Dim hOldPen As IntPtr = Win32.SelectObject(hDC, hPen) Call Win32.RoundRect(hDC, rc.Left, rc.Top, rc.Right, rc.Bottom, 10, 10) Win32.SelectObject(hDC, hOldPen) Win32.DeleteObject(hPen) e.Graphics.ReleaseHdc(hDC) MyBase.OnPaint(e) End Sub This will draw a nice rounded rectangle, but it will also fill it with a white brush, erasing what I don't want to have erased. How can I draw this without erasing the inside of the rectangle?

    Read the article

  • What is the PIXELFORMATDESCRIPTOR parameter in SetPixelFormat() used for?

    - by Mads Elvheim
    Usually when setting up OpenGL contexts, I've simply filled out a PIXELFORMATDESCRIPTOR structure with the necessary information and called ChoosePixelFormat(), followed by a call to SetPixelFormat() with the returned matching pixelformat from ChoosePixelFormat(). Then I've simply passed the initial descriptor without giving much thought of why. But now I use wglChoosePixelFormatARB() instead if ChoosePixelFormat() because I need some extended traits like sRGB and multisampling. It takes an attribute list of integers, just like XLib/GLX on Linux, not a PIXELFORMATDESCRIPTOR structure. So, do I really have to fill in a descriptor for SetPixelFormat() to use? What does SetPixelFormat() use the descriptor for when it already has the pixelformat descriptor index? Why do I have to specify the same pixelformat attributes in two different places? And which one takes precedence; the attribute list to wglChoosePixelFormatARB(), or the PIXELFORMATDESCRIPTOR attributes passed to SetPixelFormat()? Here are the function prototypes, to make the question more clear: /* Finds a best match based on a PIXELFORMATDESCRIPTOR, and returns the pixelformat index */ int ChoosePixelFormat(HDC hdc, const PIXELFORMATDESCRIPTOR *ppfd); /* Finds a best match based on an attribute list of integers and floats, and returns a list of indices of matches, with the best matches at the head. Also supports extended pixelformat traits like sRGB color space, floating-point framebuffers and multisampling. */ BOOL wglChoosePixelFormatARB(HDC hdc, const int *piAttribIList, const FLOAT *pfAttribFList, UINT nMaxFormats, int *piFormats, UINT *nNumFormats ); /* Sets the pixelformat based on the pixelformat index */ BOOL SetPixelFormat(HDC hdc, int iPixelFormat, const PIXELFORMATDESCRIPTOR *ppfd);

    Read the article

  • Per-pixel per-component alpha blending in Windows

    - by Crend King
    I have a 24-bit bitmaps with R, G, B color channels and a 24-bit bitmap with R, G, B alpha channels. I want to alpha blend the first bitmap to a HDC in GDI or RenderTarget in Direct2D with the alpha channels respectively. For example, suppose for one pixel, the bitmap color is (192, 192, 192), the HDC color is (0, 255, 255) and the alpha channels are (30, 40, 50). The final HDC color should be (22, 245, 242). I know I can BitBlt the HDC to a memory HDC first, do alpha blending by manually calculating the color of each pixel and finally BitBlt back. I just want to avoid the additional blitting and leave APIs do their job (faster since they are in kernel space). The first idea comes to my mind is to split the source bitmap into 3 red-only, green-only and blue-only 8-bit bitmaps, do normal alpha blending, then composite the 3 output bitmaps into the HDC. But I don't find a way to do the splitting and composition natively in Windows (would Direct2D layer help?). Also, the splitting and compositing may require many additional copying. The performance overhead would be too high. Or maybe do the alpha blending in 3 passes. Each pass apply the blending for one channel, while maintaining the other 2 unchanged. Thanks for any comment. EDIT: I found this question, and the answer should be good reference to this problem. However, besides AC_SRC_OVER, there is no other blending operation supported. Why don't Microsoft improve their API?

    Read the article

  • Making an owner-draw button transparent against its arbitrary background in WINCE

    - by EndsOfInvention
    Hi I am trying to place an owner-draw button transparently onto a background. I have no trouble doing this when the background is a solid colour but if the background is an image I cannot seem to get the correct HDC (handle to device context) to Bitblt() the area that button covers. The HDC that is passed as part of the DRAWITEMSTRUCT gives me a button-default-grey area. If I attempt to get the parent of the HWND and then the device context of that i.e pdc = GetDC(GetParent(hWnd)); then the background that gets BitBlt'd is the background of the last painted window. I hope this question makes sense. this is the code I have: pdis = (LPDRAWITEMSTRUCT)(lParam); hdc = pdis->hDC; button = pdis->CtlID - IDC_BUTOFFSET; //pdc = GetDC((hWnd)); pdc = GetDC(GetParent(hWnd)); hbm = CreateCompatibleBitmap(pdc, Buttons_[button]->bc.Size.cx, Buttons_[button]->bc.Size.cy); SelectObject(hdc, hbm); BitBlt(hdc, 0, 0, Buttons_[button]->bc.Size.cx, Buttons_[button]->bc.Size.cy, pdc, Buttons_[button]->bc.Position.x, Buttons_[button]->bc.Position.y, SRCCOPY); TIA Best regards Ends

    Read the article

  • How do you convert bytes of bitmap into x, y location of pixels?

    - by Jon
    I have a win32 program that creates a bitmap screenshot. I am trying to figure out the x and y coordinates of the bmBits. Below is the code I have so far: UINT32 nScreenX = GetSystemMetrics(SM_CXSCREEN); UINT32 nScreenY = GetSystemMetrics(SM_CYSCREEN); HDC hdc = GetDC(NULL); HDC hdcScreen = CreateCompatibleDC(hdc); HBITMAP hbmpScreen = CreateDIBSection( hdcDesk, ( BITMAPINFO* )&bitmapInfo.bmiHeader,DIB_RGB_COLORS, &bitmapDataPtr, NULL, 0 ); SelectObject(hdcScreen, hbmpScreen); BitBlt(hdcScreen, 0, 0, nScreenX , nScreenY , hdc, 0, 0, SRCCOPY); ReleaseDC(NULL, hdc); BITMAP bmpScreen; GetObject(hbmpScreen, sizeof(bmpScreen), &bmpScreen); DWORD *pScreenPixels = (DWORD*)bmpScreen.bmBits, UINT32 x = 0; UINT32 y = 0; UINT32 nCntPixels = nScreenX * nScreenY; for(int n = 0; n < nCntPixels; n++) { x = n % nScreenX; y = n / nScreenX; //do stuff with the x and y vals } The code seem correct to me but, when I use this code the x and y values appear to be off. Where does the first pixel of bmBits start? When x and y are both 0. Is that the top left, bottom left, bottom right or top right? Thanks.

    Read the article

  • C++ Printing: Printer jams, what am I doing wrong?

    - by Kleas
    I have a problem with printing in C++. As far as I know, this code used to work on my previous printer, but ever since I got another one (an HP C7280) it started giving problems. Whenever I try to print anything, even an empty page, the page JAMS the printer. I have to manualy remove the page from the printer. I have no clue why this is happening. Am I doing something wrong, is it a driver problem, are there better ways to print in C++? I am using Windows 7 64 bit, but this problem also presented itself when I was using Windows Vista 64 bit. I use the following code: PRINTDLG pd; ZeroMemory(&pd, sizeof(pd)); pd.lStructSize = sizeof(pd); pd.hwndOwner = mainWindow; pd.hDevMode = NULL; pd.hDevNames = NULL; pd.Flags = PD_USEDEVMODECOPIESANDCOLLATE | PD_RETURNDC; pd.nCopies = 1; pd.nMinPage = 1; pd.nMaxPage = 0xFFFF; if (PrintDlg(&pd)==TRUE) { DOCINFO di; di.cbSize = sizeof(DOCINFO); di.lpszDocName = "Rumitec en Roblaco Print"; di.lpszOutput = (LPTSTR)NULL; di.fwType = 0; // Start printing StartDoc(pd.hDC, &di); StartPage(pd.hDC); initPrinter(pd.hDC); // ... // Do some drawing // ... // End printing EndPage(pd.hDC); EndDoc(pd.hDC); DeleteDC(pd.hDC); } Am I doing something wrong? Alternatively, is there a better, easier, more modern way to do it?

    Read the article

  • Performing full screen grab in windows

    - by Steven Lu
    I am working an idea that involves getting a full capture of the screen including windows and apps, analyzing it, and then drawing items back onto the screen, as an overlay. I want to learn image processing techniques and I could get lots of data to work with if I can directly access the Windows screen. I could use this to build automation tools the likes of which have never been seen before. More on that later. I have full screen capture working for the most part. HWND hwind = GetDesktopWindow(); HDC hdc = GetDC(hwind); int resx = GetSystemMetrics(SM_CXSCREEN); int resy = GetSystemMetrics(SM_CYSCREEN); int BitsPerPixel = GetDeviceCaps(hdc,BITSPIXEL); HDC hdc2 = CreateCompatibleDC(hdc); BITMAPINFO info; info.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); info.bmiHeader.biWidth = resx; info.bmiHeader.biHeight = resy; info.bmiHeader.biPlanes = 1; info.bmiHeader.biBitCount = BitsPerPixel; info.bmiHeader.biCompression = BI_RGB; void *data; hbitmap = CreateDIBSection(hdc2,&info,DIB_RGB_COLORS,(void**)&data,0,0); SelectObject(hdc2,hbitmap); Once this is done, I can call this repeatedly: BitBlt(hdc2,0,0,resx,resy,hdc,0,0,SRCCOPY); The cleanup code (I have no idea if this is correct): DeleteObject(hbitmap); ReleaseDC(hwind,hdc); if (hdc2) { DeleteDC(hdc2); } Every time BitBlt is called it grabs the screen and saves it in memory I can access thru data. Performance is somewhat satisfactory. BitBlt executes in 50 milliseconds (sometimes as low as 33ms) at 1920x1200x32. What surprises me is that when I switch display mode to 16 bit, 1920x1200x16, either through my graphics settings beforehand, or by using ChangeDisplaySettings, I get a massively improved screen grab time between 1ms and 2ms, which cannot be explained by the factor of two reduction in bit-depth. Using CreateDIBSection (as above) offers a significant speed up when in 16-bit mode, compared to if I set up with CreateCompatibleBitmap (6-7ms/f). Does anybody know why dropping to 16bit causes such a speed increase? Is there any hope for me to grab 32bit at such speeds? if not for the color depth, but for not forcing a change of screen buffer modes and the awful flickering.

    Read the article

  • My linux server takes more than an hour to boot. Suggestions?

    - by jamieb
    I am building a CentOS 5.4 system that boots off a compact flash card using a card reader that emulates an IDE drive. It literally takes about an hour to boot. The ultra-slow part occurs when Grub is loading the kernel. Once that's done, the rest of the boot process only takes about a minute to get to a login prompt. Does anyone have any suggestions? I suspect that it may have to do with UDMA. Everything IDE-related in my BIOS seems to checkout. The read performance hdparm is telling me 1.77 MB/s. Ouch! (But even at that rate, it still shouldn't take an hour to decompress and load the kernel) [root@server ~]# hdparm -tT /dev/hdc /dev/hdc: Timing cached reads: 2444 MB in 2.00 seconds = 1222.04 MB/sec Timing buffered disk reads: 6 MB in 3.39 seconds = 1.77 MB/sec Trying to enable DMA is a no-go though: [root@server ~]# hdparm -d1 /dev/hdc /dev/hdc: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted using_dma = 0 (off) Here's some command outputs that might help: System [root@server ~]# uname -a Linux server.localdomain 2.6.18-164.el5xen #1 SMP Thu Sep 3 04:47:32 EDT 2009 i686 i686 i386 GNU/Linux PCI info: [root@server ~]# lspci -v 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02) Subsystem: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation 82945G/GZ Integrated Graphics Controller Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at fdf00000 (32-bit, non-prefetchable) [size=512K] I/O ports at ff00 [size=8] Memory at d0000000 (32-bit, prefetchable) [size=256M] Memory at fdf80000 (32-bit, non-prefetchable) [size=256K] Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at fe00 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at fd00 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 Flags: bus master, medium devsel, latency 0, IRQ 18 I/O ports at fc00 [size=32] 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at fb00 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller Flags: bus master, medium devsel, latency 0, IRQ 16 Memory at fdfff000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: fde00000-fdefffff Prefetchable memory behind bridge: 00000000fdd00000-00000000fdd00000 Capabilities: [50] #0d [0000] 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) Subsystem: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge Flags: bus master, medium devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01) (prog-if 80 [Master]) Subsystem: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 17 I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at f800 [size=16] Capabilities: [70] Power Management version 2 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) Subsystem: Intel Corporation 82801G (ICH7 Family) SMBus Controller Flags: medium devsel, IRQ 17 I/O ports at 0500 [size=32] 01:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at de00 [size=256] Memory at fdeff000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 01:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ Flags: bus master, medium devsel, latency 32, IRQ 17 I/O ports at dc00 [size=256] Memory at fdefe000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 01:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at da00 [size=256] Memory at fdefd000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 hdparm ouput: [root@server ~]# hdparm /dev/hdc /dev/hdc: multcount = 0 (off) IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 8146/16/63, sectors = 8211168, start = 0 [root@server ~]# hdparm -I /dev/hdc /dev/hdc: ATA device, with non-removable media Model Number: InnoDisk Corp. - iCF4000 4GB Serial Number: 20091023AACA70000753 Firmware Revision: 081107 Standards: Supported: 5 Likely used: 6 Configuration: Logical max current cylinders 8146 8146 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 8211168 LBA user addressable sectors: 8211168 device size with M = 1024*1024: 4009 MBytes device size with M = 1000*1000: 4204 MBytes (4 GB) Capabilities: LBA, IORDY(can be disabled) Standby timer values: spec'd by Vendor R/W multiple sector transfer: Max = 2 Current = 2 DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * Power Management feature set * WRITE_BUFFER command * READ_BUFFER command * NOP cmd * CFA feature set * Mandatory FLUSH_CACHE HW reset results: CBLID- above Vih Device num = 0 CFA power mode 1: enabled and required by some commands Maximum current = 100ma Checksum: correct

    Read the article

  • SetPixelFormat is not creating an alpha channel for OpenGL

    - by i_photon
    I've been able to do this before, and I don't know what changed between two weeks ago and the last windows update, but for some reason SetPixelFormat isn't creating an alpha channel. gDebugger shows that the window's back buffer only has 3 channels. White+0 alpha renders as white. So there is something inherently wrong with what I was doing, or an update broke it. The code below should be paste-able into an empty VS project. #include <Windows.h> #include <dwmapi.h> #include <gl/GL.h> #pragma comment(lib,"opengl32.lib") #pragma comment(lib,"dwmapi.lib") HWND hWnd = 0; HDC hDC = 0; HGLRC hRC = 0; LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM); int APIENTRY WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ) { WNDCLASSEX wcex = {0}; wcex.cbSize = sizeof(WNDCLASSEX); wcex.lpfnWndProc = WndProc; wcex.hCursor = LoadCursor(NULL, IDC_ARROW); wcex.lpszClassName = TEXT("why_class"); RegisterClassEx(&wcex); // no errors hWnd = CreateWindowEx( NULL, TEXT("why_class"), TEXT("why_window"), WS_OVERLAPPEDWINDOW, 128,128, 256,256, NULL, NULL, hInstance, NULL ); // no errors PIXELFORMATDESCRIPTOR pfd = {0}; pfd.nSize = sizeof(pfd); pfd.nVersion = 1; pfd.dwFlags = PFD_DRAW_TO_WINDOW| PFD_SUPPORT_OPENGL| PFD_DOUBLEBUFFER| PFD_SUPPORT_COMPOSITION; pfd.cColorBits = 32; pfd.cAlphaBits = 8; // need an alpha channel pfd.cDepthBits = 24; pfd.cStencilBits = 8; hDC = GetDC(hWnd); int i = ChoosePixelFormat(hDC,&pfd); SetPixelFormat(hDC,i,&pfd); // no errors hRC = wglCreateContext(hDC); // no errors wglMakeCurrent(hDC,hRC); // no errors // EDIT: Turn on alpha testing (which actually won't // fix the clear color problem below) glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA); // EDIT: Regardless of whether or not GL_BLEND is enabled, // a clear color with an alpha of 0 should (or did at one time) // make this window transparent glClearColor( 0,0,0, // if this is (1,1,1), the window renders // solid white regardless of the alpha 0 // changing the alpha here has some effect ); DWM_BLURBEHIND bb = {0}; bb.dwFlags = DWM_BB_ENABLE|DWM_BB_TRANSITIONONMAXIMIZED; bb.fEnable = TRUE; bb.fTransitionOnMaximized = TRUE; DwmEnableBlurBehindWindow(hWnd,&bb); // no errors ShowWindow(hWnd, SW_SHOWNORMAL); UpdateWindow(hWnd); // no errors MSG msg = {0}; while(true){ GetMessage(&msg,NULL,NULL,NULL); if(msg.message == WM_QUIT){ return (int)msg.wParam; } TranslateMessage(&msg); DispatchMessage(&msg); glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT); glBegin(GL_TRIANGLES); // this vertex should be transparent, // as it was when I last built this test // // it renders as white glColor4f(1,1,1,0); glVertex2f(0,0); glColor4f(0,1,1,1); glVertex2f(1,0); glColor4f(1,0,1,1); glVertex2f(0,1); glEnd(); SwapBuffers(hDC); } return (int)msg.wParam; } LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_DESTROY: { PostQuitMessage(0); }return 0; default: break; } return DefWindowProc(hWnd, message, wParam, lParam); }

    Read the article

1 2 3 4 5 6  | Next Page >