From: Florian E. <fl...@bu...> - 2013-05-16 20:59:09
Attachments:
signature.asc
freeglut-2.8.1-dpi-awareness.patch
|
Hello everybody, here's a small patch to make freeglut DPI-aware. When the screen is set to more DPI than the default (96), ScreenToClient (which is used at various points within freeglut) will return junk in some situations. When the application is DPI-aware as indicated by the API call + the DPI query, ScreenToClient works properly again. Note: I am not 100% sure if this has any potential side effects. The patch fixed several issues I was having on a high-DPI touchscreen (e.g. wrong touch coordinates, massive flickering when switching to fullscreen), but some additional testing would probably be a good idea. Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL |
From: Diederick C. N. <dc...@gm...> - 2013-05-19 15:46:07
|
Hi Florian, Thanks for the patch, I am not sure if this fix by itself is good, but i am happy it seems to work for you. Looking at the patch you attached, would actually only calling SetProcessDPIAware() be enough? No need for the other lines as they are not used? Best, Dee On Thu, May 16, 2013 at 11:52 PM, Florian Echtler <fl...@bu...> wrote: > Hello everybody, > > here's a small patch to make freeglut DPI-aware. When the screen is set > to more DPI than the default (96), ScreenToClient (which is used at > various points within freeglut) will return junk in some situations. > When the application is DPI-aware as indicated by the API call + the DPI > query, ScreenToClient works properly again. > > Note: I am not 100% sure if this has any potential side effects. The > patch fixed several issues I was having on a high-DPI touchscreen (e.g. > wrong touch coordinates, massive flickering when switching to > fullscreen), but some additional testing would probably be a good idea. > > Best regards, Florian > -- > SENT FROM MY DEC VT50 TERMINAL > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Diederick C. N. <dc...@gm...> - 2013-05-19 15:50:01
|
Also, reading the docs on this function, it might not be the best thing to do: http://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx Maybe we should check with IsProcessDPIAware and issue a warning if the developer did not set it? Reading this: http://kevinragsdale.net/is-your-app-dpi-aware/, it seems there are a host of potential side-effects to marking the program as DPI aware too.. Not sure what would be best here... Best, Dee On Sun, May 19, 2013 at 11:46 PM, Diederick C. Niehorster <dc...@gm...> wrote: > Hi Florian, > > Thanks for the patch, I am not sure if this fix by itself is good, but > i am happy it seems to work for you. Looking at the patch you > attached, would actually only calling SetProcessDPIAware() be enough? > No need for the other lines as they are not used? > > Best, > Dee > > On Thu, May 16, 2013 at 11:52 PM, Florian Echtler <fl...@bu...> wrote: >> Hello everybody, >> >> here's a small patch to make freeglut DPI-aware. When the screen is set >> to more DPI than the default (96), ScreenToClient (which is used at >> various points within freeglut) will return junk in some situations. >> When the application is DPI-aware as indicated by the API call + the DPI >> query, ScreenToClient works properly again. >> >> Note: I am not 100% sure if this has any potential side effects. The >> patch fixed several issues I was having on a high-DPI touchscreen (e.g. >> wrong touch coordinates, massive flickering when switching to >> fullscreen), but some additional testing would probably be a good idea. >> >> Best regards, Florian >> -- >> SENT FROM MY DEC VT50 TERMINAL >> >> ------------------------------------------------------------------------------ >> AlienVault Unified Security Management (USM) platform delivers complete >> security visibility with the essential security capabilities. Easily and >> efficiently configure, manage, and operate all of your security controls >> from a single console and one unified framework. Download a free trial. >> http://p.sf.net/sfu/alienvault_d2d >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> |
From: Florian E. <fl...@bu...> - 2013-06-01 08:31:28
Attachments:
signature.asc
|
Hello Diederick, thanks for your feedback! On 19.05.2013 17:49, Diederick C. Niehorster wrote: > Also, reading the docs on this function, it might not be the best thing to do: > http://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx I know that the docs suggest to set a flag in the manifest, but I was assuming that GLUT might be able to handle this transparently. OTOH, if DPI awareness is to be done correctly, it would probably require some help from the developer, too. > Maybe we should check with IsProcessDPIAware and issue a warning if > the developer did not set it? That might be an alternative. AFAICT, if the DPI awareness is set outside of FreeGLUT, then this has to happen before glutInit() is called. > Reading this: http://kevinragsdale.net/is-your-app-dpi-aware/, it > seems there are a host of potential side-effects to marking the > program as DPI aware too.. Hmm, OK, I didn't think of other application parts which might use regular GUI elements (which would then presumably be messed up). >> Thanks for the patch, I am not sure if this fix by itself is good, but >> i am happy it seems to work for you. Looking at the patch you >> attached, would actually only calling SetProcessDPIAware() be enough? >> No need for the other lines as they are not used? AFAICT you need to set the flag _and_ query the values, doing only one of both doesn't have any effect. > Not sure what would be best here... You're perhaps right about using IsProcessDPIAware. I'm thinking it might be an option to still put the query functions into FreeGLUT and just remove the SetProcessDPIAware call. >> On Thu, May 16, 2013 at 11:52 PM, Florian Echtler <fl...@bu...> wrote: >>> Hello everybody, >>> >>> here's a small patch to make freeglut DPI-aware. When the screen is set >>> to more DPI than the default (96), ScreenToClient (which is used at >>> various points within freeglut) will return junk in some situations. >>> When the application is DPI-aware as indicated by the API call + the DPI >>> query, ScreenToClient works properly again. >>> >>> Note: I am not 100% sure if this has any potential side effects. The >>> patch fixed several issues I was having on a high-DPI touchscreen (e.g. >>> wrong touch coordinates, massive flickering when switching to >>> fullscreen), but some additional testing would probably be a good idea. >>> >>> Best regards, Florian >>> -- >>> SENT FROM MY DEC VT50 TERMINAL -- SENT FROM MY DEC VT50 TERMINAL |
From: Diederick C. N. <dc...@gm...> - 2014-01-22 05:51:01
|
Hi Florian, I have just come back to this, sorry for the very long delay on it. I guess the best way to do things is that through a new glutInit function the user can request the application to declare itself DPI aware. I have quickly implemented this here: https://github.com/dcnieho/FreeGLUT/tree/feature_DPI_awareness Remaining issues: - http://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx actually says to use SetProcessDPIAwareness (documented here: http://msdn.microsoft.com/en-us/library/windows/desktop/dn302122(v=vs.85).aspx). But that, according to the comments, does not seem to play nicely with multiple monitors (or it is a per monitor setting??). This is a complex issue that i have no experience with, maybe you can shine some light on it? - SetProcessDPIAware is only available for Vista and later. As such, we'll have to dynamic load it. - Some docs will be needed for glutInitDPIAware, explaining when to use it and possible issues that come with it. I am still not sure we should be adding this at all to FreeGLUT, unless there is a way this can work transparently (and be default-on). Is there any chance this breaks existing user code? I guess if user have a program with a GUI and also a openGL window using freeglut, things could get ugly here (and init may be called too later, due to which the setting of dpi awareness is ignored by windows). Maybe, a short section in the manual simply discussing the issues is all that is needed, so users are made aware of the issues with high dpi screens on windows. Could you look into this further and maybe make some pull requests? Thanks, Dee On Sat, Jun 1, 2013 at 4:31 PM, Florian Echtler <fl...@bu...> wrote: > Hello Diederick, > > thanks for your feedback! > > On 19.05.2013 17:49, Diederick C. Niehorster wrote: >> Also, reading the docs on this function, it might not be the best thing to do: >> http://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx > I know that the docs suggest to set a flag in the manifest, but I was > assuming that GLUT might be able to handle this transparently. OTOH, if > DPI awareness is to be done correctly, it would probably require some > help from the developer, too. > >> Maybe we should check with IsProcessDPIAware and issue a warning if >> the developer did not set it? > That might be an alternative. AFAICT, if the DPI awareness is set > outside of FreeGLUT, then this has to happen before glutInit() is called. > >> Reading this: http://kevinragsdale.net/is-your-app-dpi-aware/, it >> seems there are a host of potential side-effects to marking the >> program as DPI aware too.. > Hmm, OK, I didn't think of other application parts which might use > regular GUI elements (which would then presumably be messed up). > >>> Thanks for the patch, I am not sure if this fix by itself is good, but >>> i am happy it seems to work for you. Looking at the patch you >>> attached, would actually only calling SetProcessDPIAware() be enough? >>> No need for the other lines as they are not used? > AFAICT you need to set the flag _and_ query the values, doing only one > of both doesn't have any effect. > >> Not sure what would be best here... > You're perhaps right about using IsProcessDPIAware. I'm thinking it > might be an option to still put the query functions into FreeGLUT and > just remove the SetProcessDPIAware call. > >>> On Thu, May 16, 2013 at 11:52 PM, Florian Echtler <fl...@bu...> wrote: >>>> Hello everybody, >>>> >>>> here's a small patch to make freeglut DPI-aware. When the screen is set >>>> to more DPI than the default (96), ScreenToClient (which is used at >>>> various points within freeglut) will return junk in some situations. >>>> When the application is DPI-aware as indicated by the API call + the DPI >>>> query, ScreenToClient works properly again. >>>> >>>> Note: I am not 100% sure if this has any potential side effects. The >>>> patch fixed several issues I was having on a high-DPI touchscreen (e.g. >>>> wrong touch coordinates, massive flickering when switching to >>>> fullscreen), but some additional testing would probably be a good idea. >>>> >>>> Best regards, Florian >>>> -- >>>> SENT FROM MY DEC VT50 TERMINAL > -- > SENT FROM MY DEC VT50 TERMINAL > |
From: Florian E. <fl...@bu...> - 2014-01-22 15:11:32
Attachments:
signature.asc
|
Hello Diederick, never mind, thanks for getting back to this. On 22.01.2014 06:50, Diederick C. Niehorster wrote: > Hi Florian, > > I have just come back to this, sorry for the very long delay on it. > > I guess the best way to do things is that through a new glutInit > function the user can request the application to declare itself DPI > aware. I have quickly implemented this here: > https://github.com/dcnieho/FreeGLUT/tree/feature_DPI_awareness Seems like a very sensible solution. Perhaps save the queried DPI values as fields of fgDisplay, like in the first patch? Could add a glutGet to retrieve them later... > Remaining issues: > - http://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx > actually says to use SetProcessDPIAwareness (documented here: > http://msdn.microsoft.com/en-us/library/windows/desktop/dn302122(v=vs.85).aspx). Link seems to be broken? > But that, according to the comments, does not seem to play nicely with > multiple monitors (or it is a per monitor setting??). This is a > complex issue that i have no experience with, maybe you can shine some > light on it? I think it's a global setting, but I haven't tried any of this with multiple displays yet. > - SetProcessDPIAware is only available for Vista and later. As such, > we'll have to dynamic load it. Oh, drat. ... Hm. How about this: just call GetDeviceCaps(LOGPIXELSX) in fgPlatformInitialize and leave the entire handling of SetProcessDPIAware/manifest/whatever to the application? That way, the context doesn't have to be exposed to the app and if noone cares about DPI awareness, the GetDeviceCaps call will not have any side effects. > - Some docs will be needed for glutInitDPIAware, explaining when to > use it and possible issues that come with it. > > I am still not sure we should be adding this at all to FreeGLUT, > unless there is a way this can work transparently (and be default-on). > Is there any chance this breaks existing user code? I guess if user > have a program with a GUI and also a openGL window using freeglut, > things could get ugly here (and init may be called too later, due to > which the setting of dpi awareness is ignored by windows). Maybe, a > short section in the manual simply discussing the issues is all that > is needed, so users are made aware of the issues with high dpi screens > on windows. I think the above solution would work; I only built a FreeGLUT patch in the first place because of the required access to the device context... > Could you look into this further and maybe make some pull requests? Will do. Best, Florian > Thanks, > Dee > > On Sat, Jun 1, 2013 at 4:31 PM, Florian Echtler <fl...@bu...> wrote: >> Hello Diederick, >> >> thanks for your feedback! >> >> On 19.05.2013 17:49, Diederick C. Niehorster wrote: >>> Also, reading the docs on this function, it might not be the best thing to do: >>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx >> I know that the docs suggest to set a flag in the manifest, but I was >> assuming that GLUT might be able to handle this transparently. OTOH, if >> DPI awareness is to be done correctly, it would probably require some >> help from the developer, too. >> >>> Maybe we should check with IsProcessDPIAware and issue a warning if >>> the developer did not set it? >> That might be an alternative. AFAICT, if the DPI awareness is set >> outside of FreeGLUT, then this has to happen before glutInit() is called. >> >>> Reading this: http://kevinragsdale.net/is-your-app-dpi-aware/, it >>> seems there are a host of potential side-effects to marking the >>> program as DPI aware too.. >> Hmm, OK, I didn't think of other application parts which might use >> regular GUI elements (which would then presumably be messed up). >> >>>> Thanks for the patch, I am not sure if this fix by itself is good, but >>>> i am happy it seems to work for you. Looking at the patch you >>>> attached, would actually only calling SetProcessDPIAware() be enough? >>>> No need for the other lines as they are not used? >> AFAICT you need to set the flag _and_ query the values, doing only one >> of both doesn't have any effect. >> >>> Not sure what would be best here... >> You're perhaps right about using IsProcessDPIAware. I'm thinking it >> might be an option to still put the query functions into FreeGLUT and >> just remove the SetProcessDPIAware call. >> >>>> On Thu, May 16, 2013 at 11:52 PM, Florian Echtler <fl...@bu...> wrote: >>>>> Hello everybody, >>>>> >>>>> here's a small patch to make freeglut DPI-aware. When the screen is set >>>>> to more DPI than the default (96), ScreenToClient (which is used at >>>>> various points within freeglut) will return junk in some situations. >>>>> When the application is DPI-aware as indicated by the API call + the DPI >>>>> query, ScreenToClient works properly again. >>>>> >>>>> Note: I am not 100% sure if this has any potential side effects. The >>>>> patch fixed several issues I was having on a high-DPI touchscreen (e.g. >>>>> wrong touch coordinates, massive flickering when switching to >>>>> fullscreen), but some additional testing would probably be a good idea. >>>>> >>>>> Best regards, Florian >>>>> -- >>>>> SENT FROM MY DEC VT50 TERMINAL >> -- >> SENT FROM MY DEC VT50 TERMINAL >> -- SENT FROM MY DEC VT50 TERMINAL |
From: Diederick C. N. <dc...@gm...> - 2014-01-23 05:29:17
|
Hi Florian, Thanks for looking into it further! Ok, lets keep the solution light weight then if that would be sufficient, with some docs to tell the user what to do on the windows side to make things work. Then there is no need for new glutInit function or anything, just that one GetDeviceCaps line. The links work for me, did part of the URL get cut off or something added to it by your email reader? Best, Dee On Wed, Jan 22, 2014 at 10:54 PM, Florian Echtler <fl...@bu...> wrote: > Hello Diederick, > > never mind, thanks for getting back to this. > > On 22.01.2014 06:50, Diederick C. Niehorster wrote: >> Hi Florian, >> >> I have just come back to this, sorry for the very long delay on it. >> >> I guess the best way to do things is that through a new glutInit >> function the user can request the application to declare itself DPI >> aware. I have quickly implemented this here: >> https://github.com/dcnieho/FreeGLUT/tree/feature_DPI_awareness > Seems like a very sensible solution. Perhaps save the queried DPI values > as fields of fgDisplay, like in the first patch? Could add a glutGet to > retrieve them later... > >> Remaining issues: >> - http://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx >> actually says to use SetProcessDPIAwareness (documented here: >> http://msdn.microsoft.com/en-us/library/windows/desktop/dn302122(v=vs.85).aspx). > Link seems to be broken? > >> But that, according to the comments, does not seem to play nicely with >> multiple monitors (or it is a per monitor setting??). This is a >> complex issue that i have no experience with, maybe you can shine some >> light on it? > I think it's a global setting, but I haven't tried any of this with > multiple displays yet. > >> - SetProcessDPIAware is only available for Vista and later. As such, >> we'll have to dynamic load it. > Oh, drat. ... Hm. How about this: just call GetDeviceCaps(LOGPIXELSX) in > fgPlatformInitialize and leave the entire handling of > SetProcessDPIAware/manifest/whatever to the application? That way, the > context doesn't have to be exposed to the app and if noone cares about > DPI awareness, the GetDeviceCaps call will not have any side effects. > >> - Some docs will be needed for glutInitDPIAware, explaining when to >> use it and possible issues that come with it. >> >> I am still not sure we should be adding this at all to FreeGLUT, >> unless there is a way this can work transparently (and be default-on). >> Is there any chance this breaks existing user code? I guess if user >> have a program with a GUI and also a openGL window using freeglut, >> things could get ugly here (and init may be called too later, due to >> which the setting of dpi awareness is ignored by windows). Maybe, a >> short section in the manual simply discussing the issues is all that >> is needed, so users are made aware of the issues with high dpi screens >> on windows. > I think the above solution would work; I only built a FreeGLUT patch in > the first place because of the required access to the device context... > >> Could you look into this further and maybe make some pull requests? > Will do. > > Best, Florian > >> Thanks, >> Dee >> >> On Sat, Jun 1, 2013 at 4:31 PM, Florian Echtler <fl...@bu...> wrote: >>> Hello Diederick, >>> >>> thanks for your feedback! >>> >>> On 19.05.2013 17:49, Diederick C. Niehorster wrote: >>>> Also, reading the docs on this function, it might not be the best thing to do: >>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx >>> I know that the docs suggest to set a flag in the manifest, but I was >>> assuming that GLUT might be able to handle this transparently. OTOH, if >>> DPI awareness is to be done correctly, it would probably require some >>> help from the developer, too. >>> >>>> Maybe we should check with IsProcessDPIAware and issue a warning if >>>> the developer did not set it? >>> That might be an alternative. AFAICT, if the DPI awareness is set >>> outside of FreeGLUT, then this has to happen before glutInit() is called. >>> >>>> Reading this: http://kevinragsdale.net/is-your-app-dpi-aware/, it >>>> seems there are a host of potential side-effects to marking the >>>> program as DPI aware too.. >>> Hmm, OK, I didn't think of other application parts which might use >>> regular GUI elements (which would then presumably be messed up). >>> >>>>> Thanks for the patch, I am not sure if this fix by itself is good, but >>>>> i am happy it seems to work for you. Looking at the patch you >>>>> attached, would actually only calling SetProcessDPIAware() be enough? >>>>> No need for the other lines as they are not used? >>> AFAICT you need to set the flag _and_ query the values, doing only one >>> of both doesn't have any effect. >>> >>>> Not sure what would be best here... >>> You're perhaps right about using IsProcessDPIAware. I'm thinking it >>> might be an option to still put the query functions into FreeGLUT and >>> just remove the SetProcessDPIAware call. >>> >>>>> On Thu, May 16, 2013 at 11:52 PM, Florian Echtler <fl...@bu...> wrote: >>>>>> Hello everybody, >>>>>> >>>>>> here's a small patch to make freeglut DPI-aware. When the screen is set >>>>>> to more DPI than the default (96), ScreenToClient (which is used at >>>>>> various points within freeglut) will return junk in some situations. >>>>>> When the application is DPI-aware as indicated by the API call + the DPI >>>>>> query, ScreenToClient works properly again. >>>>>> >>>>>> Note: I am not 100% sure if this has any potential side effects. The >>>>>> patch fixed several issues I was having on a high-DPI touchscreen (e.g. >>>>>> wrong touch coordinates, massive flickering when switching to >>>>>> fullscreen), but some additional testing would probably be a good idea. >>>>>> >>>>>> Best regards, Florian >>>>>> -- >>>>>> SENT FROM MY DEC VT50 TERMINAL >>> -- >>> SENT FROM MY DEC VT50 TERMINAL >>> > > > -- > SENT FROM MY DEC VT50 TERMINAL > |