Menu
▾
▴
Re: [Freeglut-developer] glutInitWindowPosition with negative coordinate(s)
|
From: Diederick C. N. <dc...@gm...> - 2015-11-15 21:05:48
|
Hi Vinnie, Sorry for the slow reply and thanks for the work! I have looked at glutCreateSubWindow, and can make little sense of some of it. Negative X/Y makes sense Negative W/H makes some sense in the simple case. In principle it is useful to be able to say, e.g., make a window that is 100 pixels smaller than the parent by providing width and height -100. What X and Y position do in that code i do not know, you get unexpected widths that way. The second part of the logic regarding what should happen when W/H are larger than the width/height of the parent makes no sense to me. Proposed action. For glutInitWindowPosition / -size, do as John F. proposed For subwindows, keep current logic if GLUT_ALLOW_NEGATIVE_WINDOW_POSITION is false, but make the following changes: - negative W/H simply means subtract provided width/height from parent's size. so, e.g., w = parent->State.Width + w ; (as w is negative). skip the X/Y in those calculations. - remove the bit of the logic that gets triggered when W/H are larger than the width/height of the parent. - document this (none of this is in original GLUT) if GLUT_ALLOW_NEGATIVE_WINDOW_POSITION is true - only change behavior when negative window coordinates are set. Pass them on to the OS, which may then (partially) clip the child, or do whatever it wants to do. As you said, there might be usage cases for invisible child windows (though there are better ways to do that). How does that sound? Good start on the code! I haven't tested it, but i read from the code that negative positions provided to glutPositionWindow are already passed onto the OS window manager without any filtering. So this discussion is only about glutInitWindowPosition and subwindows. All this should be clearly documented :) Cheers, Dee On Sun, Oct 18, 2015 at 2:55 AM, Vinnie Simonetti <rcm...@ho...> wrote: > FYI, this is what I have currently: > https://github.com/rcmaniac25/FreeGLUT/commit/3f66cf2 > > Vinnie > > -----Original Message----- > From: Vinnie Simonetti [mailto:rcm...@ho...] > Sent: Saturday, October 17, 2015 7:58 PM > To: 'FreeGLUT developers list' <fre...@li...> > Subject: Re: [Freeglut-developer] glutInitWindowPosition with negative > coordinate(s) > > Hey Dee, > > Indeed I have the flag and the only time anything changes is when that flag > is enabled (it's disabled by default). > > Negative coordinate for a subwindow would just mean it's partially or > entirely off the screen. Why that's needed, I don't know. But enough > graphics applications draw to separate windows and move the window to save > processing time (essentially a framebuffer to an image. Only write when > needed to the FB while the image can be constantly redrawn with minimal > additional processing). > > I checked the platforms we support, if they don't support subwindows, then > it just creates another window. > If they do support it, they all clip within the parent window. I'm not > touching the clipping, I'm just trying to figure out what the logic should > be if a negative x/y is used. The reason negative x/y/w/h exist are because > the function takes 'int' instead of 'unsigned int'. > > If anyone gets the chance, take a look at glutCreateSubWindow (fg_window.c) > and try to make heads or tails of it... > and possibly think how negative values should be handled within the > function. > > Vinnie > > -----Original Message----- > From: Diederick C. Niehorster [mailto:dc...@gm...] > Sent: Saturday, October 17, 2015 4:55 PM > To: FreeGLUT developers list <fre...@li...> > Subject: Re: [Freeglut-developer] glutInitWindowPosition with negative > coordinate(s) > > Hi Vinnie, > > There's nothing wrong with enabling negative window coordinates everywhere, > in fact, its great. As long as it doesn't break backward compatibility. So a > flag to allow it would probably need to exist. As discussed, it definitely > should for init window pos. John's proposal nails that. > > As for sub windows, they only exist within the parent window, so what would > a negative coordinate mean? It'll just get clipped. On windows at least. > Maybe leave that as is? There is something weird though with the negative > size you're mentioning. I am not familiar with that and would need to see > what it does to better know what to do with it. > > Cheers, > Dee > > On Sat, Oct 17, 2015 at 10:27 PM, Vinnie Simonetti <rcm...@ho...> > wrote: >> First off I misread the subject line. I thought it was just supporting >> negative window coordinates in general and not just the >> glutInitWindowPosition. >> >> I'm almost done implementing this for general support for all window >> position functions supporting negative coordinates, but I'm a bit >> stuck on glutCreateSubWindow. >> >> What are the expected behaviors of this? I know the for the current OS >> implementations, it's either supported and creates a "window" within >> the bounds of the parent window or isn't implemented at all. >> >> As such, the current logic seems to be as follows, correct me if wrong: >> - X/Y: if positive, leave untouched. If negative, "swap the edge it's >> offset from". As in, instead of being from the top-left, it is the >> offset from the bottom-right. >> - W/H: if positive, leave untouched. If negative, resize the window to >> be between the bottom-right corner of the window and the bounds of the >> parent window. Now, there is additional logic that is supposed to move >> the window origin, but it would never get triggered unless the size >> was greater than the parent size, in which case it mirrors the window >> coordinates so values are positive, though if you played with this, >> you could actually get the negative window positions. AKA, I think two >> different logic implementations for negative width/height exist within >> the same function and maybe shouldn't. >> >> I feel like this is not exactly what this function is supposed to do, >> and possibly it does more then it should right now. >> >> So with that, two questions: >> 1. Did I screw up and negative window coordinates should only be for >> glutInitWindowPosition? >> 2. How should enabling negative position coordinates work within >> glutCreateSubWindow? I'm currently thinking of simply disabling the >> "X/Y is negative" logic mentioned above, but it may have weird results >> with the rest of the logic. >> >> Opinions and comments are welcome, >> Vinnie >> >> -----Original Message----- >> From: Diederick C. Niehorster [mailto:dc...@gm...] >> Sent: Monday, October 12, 2015 5:00 AM >> To: FreeGLUT developers list >> <fre...@li...> >> Subject: Re: [Freeglut-developer] glutInitWindowPosition with negative >> coordinate(s) >> >> Hi all, >> >> On Sun, Oct 11, 2015 at 6:26 AM, Vinnie Simonetti >> <rcm...@ho...> >> wrote: >>> So should this flag be implemented? A > GLUT_ALLOW_NEGATIVE_WINDOW_POSITION? >> >> John made a great plan there, yes we should implement this and that's >> a good name for the flag. >> >> Thanks also Vinnie for working fixing the two install issues. I'll get >> to putting them in shortly. >> >> Cheers, >> Dee >> >> ---------------------------------------------------------------------- >> ------ >> -- >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> ---------------------------------------------------------------------- >> -------- _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > ---------------------------------------------------------------------------- > -- > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > ---------------------------------------------------------------------------- > -- > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > ------------------------------------------------------------------------------ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |