About   |   Getting Started   |   Downloads   |   Documentation   |   Forum


Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Device context for hdi_core 0.7.0
05-12-2017, 02:44 AM (This post was last modified: 05-12-2017 11:46 AM by garrett.)
Post: #1
Device context for hdi_core 0.7.0
Hello. While porting my project to the latest framework version (Windows, x64) I have encountered a difficulty that I don't know how to solve. My plugin had an openGL viewport that I created out of CustomWidget like this:

Code:
    hdi::core::CustomWidget frame = hdi::core::CustomWidget(hdi::core::Rect(5, 75, 550, 520));
    HWND mHwnd = (HWND)frame.platformWidget();
    HDC mHdc = GetDC(mHwnd);

Then after some setup I used mHdc device context to initiate an opengl rendering context

Code:
    HGLRC mHglrc = wglCreateContext(mHdc);

However after porting to hdi_core 0.7.0 when I try to retrieve device contect with GetDC(mHwnd) I get a null pointer. GetLastError function retrieves ERROR_INVALID_WINDOW_HANDLE error code. I'm not really shure what to do to fix this error and retrieve device context. What can possibly cause it? Maybe there is a better way framework-wise to create an opengl context? Any advice is welcome.
Find all posts by this user
Quote this message in a reply
05-12-2017, 11:44 AM
Post: #2
RE: Device context for hdi 700
In version 0.7.0, the platform type of many UI objects changed for Windows (this is due to switching to MFC from win32).

hdi::core::Widget::platformWidget() now returns a CWnd* instead of HWND. To handle this change appropriately, include the following headers on Windows:

Code:
#define _AFX_NOFORCE_LIBS
#include <afx.h>
#include <afxwin.h>

You can then obtain the underlying HWND from the CWnd* to utilize win32 functions, or you can update your code to use MFC functions with the CWnd* directly.
Find all posts by this user
Quote this message in a reply
05-12-2017, 01:40 PM
Post: #3
RE: Device context for hdi_core 0.7.0
Thank you. This helped me solve my problem.
Find all posts by this user
Quote this message in a reply
05-15-2017, 03:27 AM (This post was last modified: 05-15-2017 03:27 AM by Gaxx.)
Post: #4
RE: Device context for hdi_core 0.7.0
There is a strange thing going on with custom widget rendering context size. This may be a mistake on my side and while easy to work around I think you should know. It looks like bottom part of it gets clipped out. Its especially easy to spot if a texture is rendered to fill the whole context.

This is how a context is retrieved right now.
Code:
    CWnd *pWnd = frame.platformWidget();
    CDC* dc = pWnd->GetDC();

    //some setup - pixel format etc.

    HGLRC mHglrc = wglCreateContext(dc->m_hDC);
    wglMakeCurrent(dc->m_hDC, mHglrc);

Did I miss something obvious here?
Find all posts by this user
Quote this message in a reply
05-17-2017, 04:44 AM
Post: #5
RE: Device context for hdi_core 0.7.0
I've done some testing on mac with rendering context retrieved from platformWidget(). It seems that clipping only occurs on windows.
Find all posts by this user
Quote this message in a reply
05-30-2017, 03:05 PM (This post was last modified: 05-30-2017 03:07 PM by garrett.)
Post: #6
RE: Device context for hdi_core 0.7.0
How much of the rendering context is clipped on Windows? If it is only a pixel or two, then I strongly suspect this is due to some internal compensations we make in hdi_core to try to keep the widgets as consistent as possible between platforms in both positioning and size.

All our widgets keep an internal state for a "compensation rect" to adjust the (x,y) and/or (width x height); for example, on Mac a ColorWell constructed at (10,20) will physically lie at (10,20) but on Windows it will physically lie at (9,19) for whatever reason. These sorts of inconsistencies vary from widget to widget, so all types have differing compensations from one another.

I believe the compensation rect on Windows for CustomWidgets is either +1 for the y-position or -1 for the height, either of which could explain a 1 or 2 px clipping since you're attempting to perform your own rendering in a frame whose bounds are slightly different in actuality from what you're expecting. On Mac there are no compensations to be made for CustomWidgets (which could additionally explain the lack of clipping on Mac).
Find all posts by this user
Quote this message in a reply
05-31-2017, 12:42 AM
Post: #7
RE: Device context for hdi_core 0.7.0
It's around 40-50 pixels, regardless of widget size.
Find all posts by this user
Quote this message in a reply
06-06-2017, 10:12 AM
Post: #8
RE: Device context for hdi_core 0.7.0
That's very strange. We don't have any problems "rendering" into the CustomWidget frame when using platform functionality (i.e. the basic win32 drawing functions, GDI, etc). So, this makes me wonder if there are any minor incompatibilities with OpenGL and MFC (at least the version of MFC shipped with VS 2010). Our new version of CORE built with VS 2015 (and hence a newer version of MFC) should be out soon, so I'd be curious to see if the issue is still present for you at that time.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)