JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20140425 05:05:33 (UTC)

20140425 05:05:33 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20140424050533.html
20140425 05:05:33 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20140425050533.html
20140425 05:07:12 * [Mike] (~Mike]@anon) Quit ()
20140425 07:28:10 * monsieur_max (~maxime@anon) has joined #jogamp
20140425 08:43:10 * zzuegg (~zzuegg@anon) has joined #jogamp
20140425 09:02:28 * zaphos (~Matthew@anon) has joined #jogamp
20140425 10:23:55 <sgothel> http://eprint.iacr.org/2013/734.pdf <- Elliptic Curve Cryptography in Practice
20140425 10:38:08 * zaphos (~Matthew@anon) Quit (Quit: Leaving.)
20140425 11:20:53 * monsieur_max (~maxime@anon) Quit (Ping timeout: 252 seconds)
20140425 11:30:50 * zaphos (~Matthew@anon) has joined #jogamp
20140425 12:00:12 * monsieur_max (~maxime@anon) has joined #jogamp
20140425 12:18:38 * zubzub (~zubzub@anon) Quit (Quit: leaving)
20140425 12:28:38 * xranby (~xranby@anon) Quit (Ping timeout: 255 seconds)
20140425 12:31:02 * xranby (~xranby@anon) has joined #jogamp
20140425 14:12:52 * xranby (~xranby@anon) Quit (Read error: Operation timed out)
20140425 14:30:35 * xranby (~xranby@anon) has joined #jogamp
20140425 15:22:23 * zaphos (~Matthew@anon) Quit (Quit: Leaving.)
20140425 15:23:18 * zaphos (~Matthew@anon) has joined #jogamp
20140425 15:52:11 <hharrison> What's the easiest way to get someone set up to try some of JOGL's unit tests, look to get an external tester to try some of the NewtAWTCanvas tests on a HighDPI mac
20140425 15:52:48 <sgothel> com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NewtCanvasAWT
20140425 15:52:51 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20140425 15:52:56 <sgothel> make/scripts$ vi tests.sh
20140425 15:53:24 <sgothel> make$ scripts/tests-x64.sh
20140425 15:53:31 <sgothel> ^^ edit that to match your needs ..
20140425 15:53:41 <sgothel> copy the test case to match your needs as well ..
20140425 15:54:06 <sgothel> @Harvey: Have you followed the BOF application ?
20140425 15:54:36 <hharrison> No, will do today
20140425 15:54:49 <sgothel> Now, if possible - you may help us get a good slot (i.e. no collision w/ Khronos ..)
20140425 15:54:52 <sgothel> thx!
20140425 15:55:30 <hharrison> Also...anybody around here actually have a HighDPI mac they can test on?
20140425 15:56:35 <sgothel> I do .. but I have scheduled that for next month ..
20140425 15:56:39 <sgothel> so if you can wait a bit ..
20140425 15:57:30 <sgothel> How about HighDPI on .. Windows, .. X11, .. ? API is available ?
20140425 15:57:53 <sgothel> We can chat about the API now if you like...
20140425 15:57:59 <hharrison> I'm not desparate, it can easily wait
20140425 15:58:42 <sgothel> i.e. there are this 2 dimensions .. one may be linear dependent on the other (integer/float scale factor)
20140425 15:59:02 <sgothel> window-size, framebuffer/drawable size
20140425 15:59:31 <hharrison> I'm not sure about API really, how likely do you think it is other vendors are going to go the same way and expose differnent DPI between the windowing toolkit and the gl surface?
20140425 15:59:33 <sgothel> selection via .. Capabilities ? or .. ?
20140425 15:59:52 <sgothel> at least I heard windows is doing that ..
20140425 15:59:59 <hharrison> really...damn
20140425 16:00:00 <sgothel> (soon or already ..)
20140425 16:00:07 <sgothel> then Android may has something .. not so sure
20140425 16:00:17 <sgothel> have to check on Wayland ..
20140425 16:00:31 <hharrison> I was kind of hoping they would just pass it through and just not expose antialiasing for those surfaces
20140425 16:00:33 <sgothel> they are all slow'ish .. since no HighDPI hardware was available ..
20140425 16:00:50 <hharrison> because at some point...why bother
20140425 16:00:56 <sgothel> right - it is just a helper ... to upscale the low-DPI version using FBOs :)
20140425 16:01:56 <sgothel> but for adding this feature, I like to have it sort of 'clean' .. i.e. one API for all .. seamless integration, sure.
20140425 16:02:18 <sgothel> case1: window-dpi << high-dpi-mode
20140425 16:02:24 <sgothel> what else ?
20140425 16:02:28 <hharrison> agreed, I guess if even one does it, having an API there is going to be needed
20140425 16:03:07 <sgothel> case1: window-dpi << framebuffer-dpi
20140425 16:03:08 <hharrison> Maybe just start with case1...and a single integer scale?
20140425 16:03:08 <sgothel> :)
20140425 16:03:30 <sgothel> OSX uses int/float scale, yes - dunno about the others, but will check
20140425 16:03:55 <hharrison> And if anyone ever does non-integer scaling (or anisotropic), deal with it then
20140425 16:04:00 <sgothel> a float scale, or 2nd integer dimension should cover it (maybe provide both metrics)
20140425 16:04:32 <sgothel> float[] dpiScaleXY, int[] framebufferDim
20140425 16:04:45 <hharrison> Just have a feeling this will be a short-term situation, eventually just have FBOs that are really big, but no antialiasing
20140425 16:04:52 <sgothel> right now we have Surface and Window
20140425 16:05:15 <sgothel> so a proper representation would be to have both providing dimensions
20140425 16:05:26 <sgothel> while Window extends Surface
20140425 16:05:36 <sgothel> (within the nativewindow package)
20140425 16:05:50 <sgothel> GLDrawable is a Surface .. hmm double check ..
20140425 16:06:17 <hharrison> Yeah, maybe internally have separate floatX-Y, but for a start, only provide API for a single integer mapping until there exists a system that does both dimensions
20140425 16:07:07 <sgothel> NativeWindow extends NativeSurface
20140425 16:07:24 <sgothel> GLDrawable has NativeSurface
20140425 16:07:49 <sgothel> as long NativeSurface represent the dimension/dpi of the actual framebuffer .. we would be fine
20140425 16:08:08 <sgothel> Then NativeWindow needs to use the actual window dimension/dpi
20140425 16:08:22 <sgothel> and review code .. whether the proper value is being used :)
20140425 16:09:14 <sgothel> NativeSurface currently exposes getWidth() getHeight()
20140425 16:09:29 <sgothel> -> width/height
20140425 16:09:41 <sgothel> since we are on the 2.2 train we can change the API - good
20140425 16:10:08 <hharrison> I don't have any hardware to test this on, all I can offer is code review
20140425 16:10:22 <sgothel> getSurf[Width|Height]() and getWin[Width|Height]() ?
20140425 16:10:30 <sgothel> ^^ more than valuable!
20140425 16:11:17 <hharrison> OK, I'll wait for you to get a HighDPI machine, that seems like the easiest way, rather than trying to debug this remotely
20140425 16:11:36 <hharrison> non-developer on the other end...too hard
20140425 16:11:55 <sgothel> ^^ API wise .. method names .. clarity
20140425 16:12:38 <hharrison> Worst case, you end up getting a highDPI machine and the NewtAWTCanvas tests work perfectly...then the bug is in my code ;-)
20140425 16:13:41 <sgothel> well .. dunno, I doubt it's working, since we don't set the HighDPI flag on OSX for the NEWT window
20140425 16:13:49 <sgothel> plus we may not use the proper dimension
20140425 16:14:09 <sgothel> just discussing the API changes required for all toolkits (AWT, NEWT, ..)
20140425 16:14:47 <hharrison> I wonder as well where this API will come into play for the individual components like NewtCanvasAWT
20140425 16:14:51 <sgothel> anybody else has an opinion ? i.e. distinguish surface/window size, etc
20140425 16:15:06 <hharrison> as opposed to the window components
20140425 16:15:25 <sgothel> we have to create a newt window w/ window-size, and the actual OSX surface/view w/ the high-dpi
20140425 16:16:05 <sgothel> here it doesn't matter whether AWT uses high-dpi, this would be the task for GLCanvas
20140425 16:16:19 <sgothel> and for pure NEWT .. same as 2 lines above
20140425 16:17:08 * zaphos (~Matthew@anon) Quit (Quit: Leaving.)
20140425 16:17:24 <sgothel> so .. how shall we allow the user to request high-dpi in our API ?
20140425 16:17:48 <sgothel> a certain surface-size value, magic defaults .. or is it just a flag (on/off) ?
20140425 16:18:02 <sgothel> (OSX: just a toggle on/off)
20140425 16:18:32 <hharrison> Can it be a switch based on the screen/display?
20140425 16:18:37 <hharrison> getPixelScale?
20140425 16:19:09 <sgothel> float[] NativeSurface::getPixelScale() - good one
20140425 16:19:36 <hharrison> Hmmm, I wonder if LWJGL or anyone else has fought this battle yet
20140425 16:19:53 <sgothel> LWJGL: They have a toggle mode using a float scale for OSX
20140425 16:20:01 <sgothel> already checked that ofc :)
20140425 16:20:10 <hharrison> But it seems just having a way to at least query the scale is a good start
20140425 16:20:14 <sgothel> last time when I posted the links here
20140425 16:20:38 <hharrison> Oh....Display.getPixelScaleFactor() is what they called theirs....seems like a common name
20140425 16:21:29 <hharrison> Then you can build a pretty easy isHighDPI method just looking for scale != 1
20140425 16:21:42 <sgothel> We could use loat[] NativeSurface::getPixelScale() --- influencing --> GLDrawable's size : compatible, i.e. no change of NativeSurface::width/height
20140425 16:22:09 <sgothel> I guess that is reasonable ..
20140425 16:22:29 <sgothel> 1 - scale < epsilon :)
20140425 16:22:57 <hharrison> display direct -> ignores HighDPI and just sizes it natively, if you enable highDPI, you get a smaller surface an rely on the highDPI scaling?
20140425 16:23:11 <hharrison> Opt in to the highDPI scaling?
20140425 16:23:28 <sgothel> I would say so, i.e. scale := 1f/1f default
20140425 16:23:41 <sgothel> even though 'natively' is actually high-dpi := on
20140425 16:24:00 <sgothel> or we can query availability and default to max native display res.
20140425 16:24:24 <hharrison> What do you think the most compatible way forward is for existing code...highdpi unaware
20140425 16:24:30 <sgothel> last time .. chatting w/ Jens I guess .. he favored max-dpi as default
20140425 16:24:52 <sgothel> compat -> scale := 1f/1f default ofc, as it is now
20140425 16:25:08 <hharrison> Just really big surfaces
20140425 16:25:14 <sgothel> otherwise, update leads to slow apps :)
20140425 16:25:42 <hharrison> slow, but still functional I suppose
20140425 16:26:06 <sgothel> maybe .. not if using screen-view FBOs alot -> out-of-memory (video)
20140425 16:28:34 <hharrison> true
20140425 16:28:58 <sgothel> so be it then ..
20140425 16:28:59 <hharrison> At least the out of memory error would be obvious
20140425 16:29:17 <hharrison> And hopefully something already being handled
20140425 16:29:21 <sgothel> you want high dpi: update and use setPixelScale(..)
20140425 16:29:46 <sgothel> we can use magic -1/-1 for max dpi
20140425 16:31:47 <sgothel> http://blogs.msdn.com/b/b8/archive/2012/03/21/scaling-to-different-screens.aspx .. dunno if related to window/surface selective dpi
20140425 16:32:43 <sgothel> good thing w/ Graph: Using high-dpi on Android tablets (i.e. 1080p on 11") .. we need no extra AA :)
20140425 16:34:17 <sgothel> http://msdn.microsoft.com/en-us/library/windows/desktop/dd464646%28v=vs.85%29.aspx
20140425 16:35:02 * monsieur_max (~maxime@anon) has joined #jogamp
20140425 16:37:38 <sgothel> looks like on Win 8.1 they have it .. :)
20140425 16:43:08 * xranby (~xranby@anon) Quit (Read error: Operation timed out)
20140425 17:00:06 * xranby (~xranby@anon) has joined #jogamp
20140425 17:46:09 <sgothel> http://www.kynosarges.org/WindowsDpi.html
20140425 18:56:03 * [Mike] (~Mike]@anon) has joined #jogamp
20140425 18:59:00 * zaphos (~Matthew@anon) has joined #jogamp
20140425 19:01:18 * rmk0 (~rmk0@anon) Quit (Ping timeout: 240 seconds)
20140425 19:02:23 * rmk0 (~rmk0@anon) has joined #jogamp
20140425 19:02:23 * rmk0 (~rmk0@anon) Quit (Changing host)
20140425 19:02:23 * rmk0 (~rmk0@anon) has joined #jogamp
20140425 19:16:38 <sgothel> .. weird .. vmkit/j3: dlopen'ing a test lib fine .. but NV and Mesa GL hangs (IMHO both have their own llvm lib .. duh!)
20140425 19:16:52 <sgothel> .. and we 'must' (?) load libGL GLOBAL .. hmm
20140425 19:20:03 <hharrison> If you actually get that working, that's quite an accomplishment, two llvms in the same space
20140425 19:21:07 <sgothel> hmm .. IMHI j3 should not load it GLOBAL itself .. dunno .. so yes, here I guess symbol/version collision happens :-/
20140425 19:41:13 * [Mike] (~Mike]@anon) Quit (Ping timeout: 252 seconds)
20140425 19:44:46 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20140425 19:45:53 * monsieur_max (~maxime@anon) has joined #jogamp
20140425 19:46:41 * monsieur_max (~maxime@anon) Quit (Remote host closed the connection)
20140425 21:55:46 * zaphos (~Matthew@anon) Quit (Quit: Leaving.)
20140426 00:06:35 * [Mike] (~Mike]@anon) has joined #jogamp
20140426 00:38:22 * hija (~hija@anon) has joined #jogamp
20140426 00:43:37 * hija (~hija@anon) Quit (Quit: hija)
20140426 01:09:06 * hharrison (~chatzilla@anon) has left #jogamp
20140426 02:45:43 * hija (~hija@anon) has joined #jogamp
20140426 04:09:37 * [Mike] (~Mike]@anon) Quit ()
20140426 05:03:57 * [Mike] (~Mike]@anon) has joined #jogamp
20140426 05:05:33 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20140426050533.html