JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20141021 05:06:24 (UTC)

20141021 05:06:24 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20141020050624.html
20141021 05:06:24 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20141021050624.html
20141021 06:28:43 * eclesia (~husky@anon) has joined #jogamp
20141021 06:28:51 <eclesia> good morning
20141021 06:45:50 * monsieur_max (~maxime@anon) has joined #jogamp
20141021 08:37:07 * gouessej (5ee4b442@anon) has joined #jogamp
20141021 08:37:15 <gouessej> Hi
20141021 08:37:31 <gouessej> I would like to know your opinion about this change: https://jogamp.org/bugzilla/show_bug.cgi?id=682
20141021 08:38:02 <gouessej> eclesia: Please look at the very last comment in my bug report
20141021 08:39:45 <eclesia> 1sec
20141021 08:43:48 <gouessej> ok
20141021 08:44:27 <eclesia> +1, kick out java packages
20141021 08:45:05 <sgothel> added more people to the CC list of bug 682
20141021 08:45:14 <sgothel> also marked it for 'version 3'
20141021 08:45:28 <sgothel> we surely need to communicate this 'political' change
20141021 08:46:27 <sgothel> still have to see whether this needs a 3.x.y version, since our versioning scheme would allow a 2.x.*, i.e. minor change incl. API change
20141021 08:47:13 <gouessej> ok
20141021 08:47:25 <eclesia> I would even be better if there could a common api between JOGL/LWJGL too, at least for the basic interfaces : GL,GL2,GL4, GLProfile and a factory .. but I guess that's asking too much
20141021 08:47:34 <gouessej> NO
20141021 08:47:45 <gouessej> Please no
20141021 08:47:59 <sgothel> I assume that LWJGL has no GL profiles like we have .. etc etc
20141021 08:48:19 <gouessej> This library has changed a lot in its third version anyway
20141021 08:48:32 <gouessej> We don't have to do that, we can't follow it
20141021 08:48:45 <gouessej> Its third version no longer supports AWT
20141021 08:49:09 <sgothel> last time I read there development .. it was more like they start to follow a more OO design as we have
20141021 08:49:16 <gouessej> yes
20141021 08:49:32 <gouessej> after having said for years that we were wrong :)
20141021 08:50:14 <gouessej> eclesia: it's not up to JOGL to be compatible with its main competitor but a common API should be created outside of jogamp
20141021 08:50:45 <gouessej> eclesia: There are already several APIs that do it, for example a part of LibGDX and NiftyGUI
20141021 08:51:00 <eclesia> I'm not asking to be compatible. make a common api would be nice
20141021 08:51:15 <eclesia> but as you said, it's a competitor, and I don't event use it
20141021 08:51:18 <eclesia> even*
20141021 08:51:40 <gouessej> eclesia: We won't adapt our public APIs to them, we're independent
20141021 08:52:06 <gouessej> eclesia: and anyway, there is no need of 2 sets of APIs doing mostly the same thing
20141021 08:52:18 <eclesia> we ? are you talking for sgothel and xranby too ?
20141021 08:52:27 <gouessej> we = jogamp
20141021 08:52:38 <gouessej> but they are free to disagree
20141021 08:53:07 <gouessej> It's impossible to follow a competitor which is free to change on its own
20141021 08:53:42 <gouessej> A common API should be outside of the JogAmp project (IMHO)
20141021 08:53:50 <sgothel> not assuming or asserting anything here - but IMHO it is bad design to make compromises to be compatible w/ another _foreign_ non-canonical API while sacrificing clarity
20141021 08:54:09 <gouessej> I completely agree with Sven
20141021 08:54:24 <sgothel> I understand that some like to utilize both products as a backend, but shall this be our concern ?
20141021 08:54:31 <eclesia> I didn't say 'follow' damn it... common api = separate package and project if you wish
20141021 08:54:47 <sgothel> jaja .. all good, this is a brainstorming :)
20141021 08:55:00 <gouessej> ok but then it's none of our (JogAmp) concern
20141021 08:55:18 <gouessej> For me, developers should use JogAmp
20141021 08:55:32 <sgothel> lets try to think the other way .. i.e. in favor of a common canonical API .. a game
20141021 08:55:41 <gouessej> If they want to use both, they use existing common APIs, a subset of LibGDX, whatever
20141021 08:56:00 <sgothel> we would need to setup a committee .. maybe w/ Khronos .. and define a new API
20141021 08:56:32 <gouessej> A really common API would align the features on the poorest of the 2, then no AWT support :(
20141021 08:56:32 <sgothel> so we make compromises to make all happy .. and future changes will involve said committee
20141021 08:57:26 * eclesia don't care about awt ^^
20141021 08:57:37 <gouessej> Personally, I refuse encouraging the use of the two APIs, it is a waste of time, effort duplication
20141021 08:57:42 <sgothel> 2 years ago I had a chat w/ John Leech (sic) and his college Barthold (sic) .. about such canonical binding, we agreed in the end its best for our man power to stay away from such committees :)
20141021 08:58:07 <sgothel> i.e. we would need like 2+ people taking care of all that communication
20141021 08:58:50 <sgothel> practically - today, we even don't communicate w/ LWJGL team
20141021 08:59:00 <gouessej> Actually, sometimes, I do
20141021 08:59:09 <sgothel> so .. this would be the 1st step
20141021 08:59:11 <sgothel> ah
20141021 08:59:24 <sgothel> good - so Julien is the liaison :)
20141021 08:59:32 <sgothel> our diplomatic channel :)
20141021 09:00:21 <gouessej> I already tried to convince them to merge the both APIs 2 years ago
20141021 09:00:29 <sgothel> ah ..
20141021 09:00:34 <sgothel> and there take ?
20141021 09:01:22 <sgothel> I guess earlier this year we had a chat about such communication - and I said I am surely open to some meetings (IRC)
20141021 09:01:22 <gouessej> Each of us wanted to keep some strong core design choices, it was impossible. Now it would be easier as the third version is closer to JogAmp
20141021 09:02:02 <sgothel> i.e. I could explain the reasoning for some higher level API hooks we have .. etc
20141021 09:02:17 <sgothel> maybe, indeed we could agree on basics like GLDrawable, GLContext, GL*
20141021 09:02:28 <gouessej> yes and those things aren't mandatory anyway, JogAmp is modular
20141021 09:03:12 <sgothel> I would ofc not assert anything, while the question remains .. why not join? On the other hand, its always great to have a choice.
20141021 09:03:25 <gouessej> I have to admit that they have worked a lot on the third version, they might be reluctant to find a solution
20141021 09:03:50 <gouessej> No really, in this case, the "choice" leads to effort duplication
20141021 09:04:00 <gouessej> drop of essential features
20141021 09:04:06 <gouessej> on their side
20141021 09:04:26 <gouessej> and I remind you that they wanted for about a year to fix their OS X support
20141021 09:04:33 <gouessej> "waited"
20141021 09:05:48 <sgothel> do they now (version 3) support desktop and embedded incl. Android ?
20141021 09:06:21 <gouessej> I'm not sure it is really homogeneous now
20141021 09:06:35 <gouessej> I'm almost sure they don't support OpenCL on Android
20141021 09:06:45 <sgothel> do they support a concurrent windowing system like NEWT, i.e. rendering / windowing events separated ?
20141021 09:07:10 <gouessej> They use GLFW
20141021 09:07:39 <gouessej> They manage multiple windows now but the source code is a lot less mature than ours in this field
20141021 09:08:09 <sgothel> that is natural ofc .. I started the new design in err .. 2008, it takes time
20141021 09:08:20 <gouessej> yes I don't blame them
20141021 09:09:37 <sgothel> so what we could do, is to have regular IRC session maybe - we can invite them to our chatroom .. and we can do some tech-talk
20141021 09:09:44 <gouessej> In my humble opinion, as long as we keep things modular, we have a chance to make it work
20141021 09:09:57 <sgothel> sure
20141021 09:09:59 <gouessej> yes, good idea
20141021 09:10:19 <gouessej> the graph API must be kept in something separate
20141021 09:10:38 <sgothel> graph: Graph-UI will have its own project, yes
20141021 09:11:16 <zubzub> common api?
20141021 09:11:25 <sgothel> the basic graph rendering .. I am not so sure about it - however, it is - or can be - packaged separately (depending on -all- jars .. etc)
20141021 09:11:25 <zubzub> *pleasedontsuckpleasedontsuckpleasedontsuck*
20141021 09:11:32 <gouessej> Maybe we'll have to show them some rudimentary example of simple loops without animators...
20141021 09:11:59 <gouessej> zubzub: don't worry
20141021 09:12:08 <zubzub> *heavy breathing*
20141021 09:12:13 <sgothel> @zuzub: nope, it's just communication .. and sharing ideas, maybe it leads somewhere
20141021 09:12:31 <gouessej> zubzub: a merge or no change, no common API (IMHO)
20141021 09:12:43 <zubzub> ok :)
20141021 09:12:58 <sgothel> so @eclesia .. good point, which maybe leads to some talks .. most important thing IMHO
20141021 09:13:10 <zubzub> as long as you keep exposing low level stuff I'm happy
20141021 09:13:31 <sgothel> sure, thats the most important feature
20141021 09:13:41 <zubzub> that's what makes javafx 3d really suck
20141021 09:13:56 <gouessej> they moved a lot of "intelligence" from native code to Java code
20141021 09:14:01 <sgothel> lets call those 'nanny APIs' :)
20141021 09:14:14 * xranby (~xranby@anon) Quit (Quit: Leaving.)
20141021 09:15:06 <gouessej> sgothel: There were a lot of tensions between them and me, you'll have to communicate a lot more than me if you don't want me to irritate them
20141021 09:15:48 <sgothel> @Julien: It's not the managed code stuff .. for convenience, which we also expose - but it is about them (javafx, etc) to imply a vendor lock - plus avoiding low-level issues w/ high-level API
20141021 09:16:01 <sgothel> :)
20141021 09:16:18 <gouessej> I was talking about the third version of our competitor
20141021 09:16:34 <sgothel> OK, so I guess I will join there IRC channel one of these days and say hello
20141021 09:17:10 <gouessej> Yes, it's a better idea, you're often more diplomatic than me
20141021 09:17:50 <sgothel> "I am not here to make new friends!" .. haha :)
20141021 09:18:26 <gouessej> this is what I often say to women :)
20141021 09:19:23 <gouessej> sgothel: Please do you have a few minutes to answer my questions about the bug 1038?
20141021 09:20:22 <sgothel> I am already answering .. and researching :)
20141021 09:20:49 <sgothel> will hit 'save changes' button soon
20141021 09:20:54 <gouessej> oh sorry, I thought that you already knew whether it concerns only "core" or bc
20141021 09:21:17 <sgothel> OpenGL [ 3.1 .. 3.3 ] -> GL3/GL3bc .. but here you have GL 3.0.1 ..
20141021 09:21:35 <sgothel> 2.1, actually
20141021 09:21:42 <gouessej> yes, 2.1
20141021 09:21:55 <gouessej> I'm still waiting for the logs
20141021 09:22:32 <gouessej> Have you look at my suggestion about USB HID?
20141021 09:22:36 <gouessej> "looked"
20141021 09:23:23 <sgothel> nope, no time yet, I assume in some bug report ..
20141021 09:23:48 <sgothel> had one bug entry w/ Xerxes about USB HID / Screen assignment
20141021 09:24:09 <gouessej> oops, maybe I used the wrong bug report
20141021 09:25:13 <gouessej> https://jogamp.org/bugzilla/show_bug.cgi?id=814#c13
20141021 09:27:59 <sgothel> valuable discussion, yup. had a chat w/ Mark these days about the 'invisible cursor' and movement. Problem here could be compatibility w/ mouse/window (loosing focus).
20141021 09:28:48 <sgothel> but should work if used carefully .. sure
20141021 09:29:15 <sgothel> the polling is one of those things ..
20141021 09:29:32 <sgothel> in NEWT we have to use it, since not all low level APIs support driven by event
20141021 09:29:57 <sgothel> USB IMHO also uses polling, no IRQ handling, like w/ old PS2 keyboards
20141021 09:30:10 <sgothel> maybe an academic issue :)
20141021 09:30:30 <gouessej> Ok but I remind you that several first person shooters have used JOGL. Actually, it's doable with a few limitations
20141021 09:31:17 <gouessej> it's already possible to get something working with the API as is
20141021 09:31:55 <sgothel> which feature ? you mean polling input (as we have now) gives enough resolution ? Or do you refer to invisible non-clipping ?
20141021 09:32:18 <sgothel> (time resolution, low lag - that is)
20141021 09:32:35 <eclesia> a new project ? JOIO for devices control : usb, keyboard,mouse,occulus-vr, nvidia-3d ... ?
20141021 09:32:50 <gouessej> It's possible to implement a quite responsible mouse look with NEWT as is
20141021 09:33:03 <sgothel> yes, not arguing that
20141021 09:33:03 <gouessej> eclesia: Newt Input API
20141021 09:33:42 <gouessej> I'll expose the raw data (but there are some security concerns)
20141021 09:34:10 <sgothel> AFAIK .. lag is about 1ms on X11, Windows, .. for propagating events
20141021 09:34:21 <gouessej> When the mouse moves, I'll expose the delta
20141021 09:34:26 <sgothel> probably less, but perf. methods are not accurate
20141021 09:35:36 <gouessej> Then it would be better to use teh raw data to create our own events
20141021 09:35:41 <gouessej> "the"
20141021 09:36:48 <sgothel> Xerxes and I added a Linux USB input device handler ..
20141021 09:36:56 <sgothel> (for raspi)
20141021 09:37:29 <gouessej> a kind of poller? I think I saw it a few months ago
20141021 09:37:30 <sgothel> LinuxMouseTracker
20141021 09:37:33 <gouessej> yes
20141021 09:38:09 <sgothel> LinuxEventDeviceTracker
20141021 09:39:01 <gouessej> Should I use libudev to handle USB HID under GNU Linux?
20141021 09:40:22 <zubzub> https://github.com/progman32/evdev-java
20141021 09:40:22 <zubzub> ?
20141021 09:40:56 <zubzub> or
20141021 09:40:57 <zubzub> http://www.freedesktop.org/wiki/Software/libinput/
20141021 09:41:33 <zubzub> if you can provide bindings for libinput you're pretty future proof I think
20141021 09:42:20 <gouessej> zubzub: https://github.com/nyholku/purejavahidapi
20141021 09:42:59 <zubzub> pff cross platform
20141021 09:43:02 <zubzub> who needs that :p
20141021 09:43:54 <gouessej> It uses udev under GNU Linux, udev is probably used by libinput
20141021 09:44:21 <zubzub> I don't know the relation between evdev and udev
20141021 09:44:56 <gouessej> evdev is the kernel, udev is in systemd
20141021 09:45:29 <sgothel> @Julien: https://jogamp.org/bugzilla/show_bug.cgi?id=1038#c7
20141021 09:45:36 <zubzub> udev is a device manager
20141021 09:45:39 <zubzub> evdev is an input manager
20141021 09:46:07 <sgothel> Xerxes used basic USB/HID *magic number* AFAIK, for the mentioned impl.
20141021 09:46:20 <sgothel> I assume evdev does the same .. following the spec
20141021 09:46:36 <sgothel> so we need to hook at this low-level .. sure
20141021 09:46:38 <gouessej> sgothel: Thanks
20141021 09:47:17 <gouessej> zubzub: Should we use evdev?
20141021 09:47:51 <zubzub> well on linux evdev is pretty much the defacto standard way of handling input
20141021 09:48:12 <zubzub> as it's not just usb/hid
20141021 09:48:15 <sgothel> LinuxEventDeviceTracker <- uses evdev AFAIK
20141021 09:48:19 <gouessej> libinput is bound to Wayland, udev to systemd, evdev is below
20141021 09:48:29 <zubzub> libinput is not bound to wayland
20141021 09:48:39 <zubzub> it's a library that abstracts evdev
20141021 09:48:50 <zubzub> so it can be used in both xorg and wayland compositors
20141021 09:49:05 <sgothel> *udev to systemd* - NOOO, for crying out loud, there is still a world w/o systemd :) udev still exists w/o systemd (I hope)
20141021 09:50:13 <gouessej> The source code of udev is in systemd according to Wikipedia
20141021 09:50:28 <sgothel> as long we follow the USB/HID specs .. we should be fine, other details are impl. specific
20141021 09:50:39 <gouessej> evdev is the good horse then lol
20141021 09:50:56 <zubzub> if you limit yourself to usb/hid then you wont have anything that's not providing input through usb, no?
20141021 09:50:58 <gouessej> and it works on the Pi
20141021 09:51:03 <sgothel> @Julien: Ha - maybe that J.P. likes to do that now .. taking over the world, however ..
20141021 09:51:21 <zubzub> "libinput is a generic input device handling library. It abstracts commonly-used concepts such as keyboard, pointer and touchpad handling behind an API."
20141021 09:51:54 <sgothel> @zuzub: the highes availability is now w/ USB/HID .. libinput maybe available on some systems
20141021 09:52:04 <sgothel> so .. yes and yes :)
20141021 09:52:10 <gouessej> sgothel: What do you mean? Maybe I'm silly today
20141021 09:52:22 <zubzub> http://who-t.blogspot.be/2014/09/libinput-common-input-stack-for-wayland.html
20141021 09:52:28 <sgothel> that if we define an API, we should use low-level specs
20141021 09:52:37 <sgothel> implementation of the same, may use libinput
20141021 09:52:45 <sgothel> and other things .. on other platforms
20141021 09:53:00 <zubzub> yeah libinput is still in it's infancy
20141021 09:53:06 <sgothel> Windows probably has no libinput .. etc etc
20141021 09:53:18 <zubzub> libinput => linux yup
20141021 09:53:18 <sgothel> may I remind you all: we run on evil platforms as well :)
20141021 09:53:32 <zubzub> 11:42 < zubzub> pff cross platform
20141021 09:53:32 <zubzub> 11:43 < zubzub> who needs that :p
20141021 09:53:33 <zubzub> :p
20141021 09:53:39 <zubzub> j/k
20141021 09:53:42 <sgothel> haha
20141021 09:54:08 <gouessej> There is IOKit for Mac
20141021 09:54:16 <gouessej> There is SetupAPI for Windows
20141021 09:54:47 <sgothel> So, if we can expose USB/HID cross-platform - that would be an awesome start I guess
20141021 09:55:20 <sgothel> (if it does not exist already)
20141021 09:56:07 <gouessej> There are 2 APIs doing that including the one I quoted (based on JNA)
20141021 09:56:31 <sgothel> https://lists.debian.org/debian-vote/2014/10/msg00012.html <- my hope for continuing using Debian for our/my servers ..
20141021 09:57:33 <gouessej> What's wrong with systemd?
20141021 09:58:03 <sgothel> oh .. the proposal puts it best - leave us a choice damn-it
20141021 09:58:47 <sgothel> currently the Red Hat team seems to perform a do-cracy .. swallowing tons of subsystems and distributions creating dependencies
20141021 09:59:23 <sgothel> meaning: it will be very hard to create a non-systemd installation, that alone seems to be very user unfriendly
20141021 10:00:04 <gouessej> Some distros already dropped non systemd things
20141021 10:00:05 <sgothel> so, one does not need to talk about merits and fail of systemd, but currently they practically take away choice
20141021 10:00:16 <sgothel> yes, that is the point
20141021 10:00:23 <sgothel> horrible
20141021 10:00:50 <gouessej> but if systemd phagociates other projects, it will become harder not to use it
20141021 10:00:51 <sgothel> http://ewontfix.com/14/
20141021 10:00:59 <sgothel> http://ewontfix.com/15/
20141021 10:01:17 <sgothel> http://blog.lusis.org/blog/2014/09/23/end-of-linux/
20141021 10:01:28 <sgothel> http://the-world-after-systemd.ungleich.ch/
20141021 10:01:58 <sgothel> .. just to name a few critical thoughts ..
20141021 10:02:05 <gouessej> "having to reboot to upgrade your system" :(
20141021 10:02:23 <sgothel> a non mature thing is now used for the most important kernel/user level bridge ..
20141021 10:02:33 <eclesia> libusb ?
20141021 10:02:55 <sgothel> plus - the fact that subsystems now are no more maintained as standalone, is horrible!
20141021 10:03:15 <sgothel> this is beyond libusb ...
20141021 10:03:51 <sgothel> a few days I was mentioning .. systemd now even attempts to swallow graphics via dri/drm for their own console emulation .. etc etc
20141021 10:03:59 <eclesia> (just adding a solution to the list of usb binding, several lines above)
20141021 10:05:08 <gouessej> evdev seems to be low level enough for me
20141021 10:05:39 <sgothel> while I like the idea of communication of init-daemon via messages (good), it surely is bad to enforce a single solution and remove the ability of convenient adoption of such modules. yes, they say its possible *you have the source*, but really do-able for sys-admins etc ?
20141021 10:06:20 <sgothel> one more issue was raised, that systemd cannot properly *talk* to chroot daemons .. dunno though
20141021 10:07:02 <sgothel> but if one team is very emotional trying to sell me the brand new thing why removing my choice, I suddenly get quite scared :)
20141021 10:07:58 <sgothel> and I doubt there is enough manpower to co-maintain all the subsystems ..
20141021 10:08:44 <sgothel> hence 'http://debianfork.org/' would be the challenge here .. which surely is more intended as provocation to push the discussion
20141021 10:09:51 <sgothel> my opinion: all great this systemd thingy, but pls done push this down our throats w/o alternative
20141021 10:10:10 * monsieur_max1 (~maxime@anon) has joined #jogamp
20141021 10:10:11 * monsieur_max1 (~maxime@anon) Quit (Client Quit)
20141021 10:10:27 <sgothel> *dont* :)
20141021 10:13:09 <gouessej> Don't fork Debian please
20141021 10:13:22 <zubzub> yeah
20141021 10:13:25 <zubzub> fork ubuntu :x
20141021 10:15:07 <sgothel> Well, Red Hat for sure will loose quite a few customer for their next release.
20141021 10:18:48 <sgothel> @Julien: we probably can replace the JNA -> GlueGen for static bindings
20141021 10:19:33 <gouessej> yes of course
20141021 10:19:38 <gouessej> I don't want to use JNA
20141021 10:20:23 <gouessej> and we can use evdev instead of udev but it depends on what we want to do as a first step
20141021 10:22:34 <sgothel> expose USB/HID functionality .. maybe, also required for: https://jogamp.org/bugzilla/show_bug.cgi?id=812 and https://jogamp.org/bugzilla/show_bug.cgi?id=813
20141021 10:24:43 <gouessej> I think that JInput uses evdev too. If I use udev, I will have to rewrite the code based on udev later :s
20141021 10:26:17 <sgothel> evdev, udev (imho unrelated), libinput: they are all implementation details - i.e. shall not impact the design of an USB/HID API
20141021 10:27:01 <sgothel> @Julien: You are creating something for the masses here ..
20141021 10:27:27 <sgothel> coffee .. checking on family, AFK
20141021 10:27:43 <gouessej> ok, see you later
20141021 11:37:25 * monsieur_max (~maxime@anon) Quit (*.net *.split)
20141021 11:37:54 * monsieur_max (~maxime@anon) has joined #jogamp
20141021 11:38:09 <eclesia> has someone tryed to make a nice sky, with clouds, rain ?
20141021 11:41:38 * doev (~doev@anon) has joined #jogamp
20141021 12:02:36 <gouessej> eclesia: My skybox is ugly
20141021 12:04:07 <eclesia> I mean high end rain effect, with shaders
20141021 12:04:23 <eclesia> not a skybox
20141021 12:15:04 <gouessej> My skills with shaders are low...
20141021 12:15:23 <eclesia> I know, you dislike shaders ^^
20141021 12:15:31 <gouessej> lol no
20141021 12:24:50 <eclesia> don't be shy :D you always talk about old api, low end opengl 1.1, awt ...etc...
20141021 12:25:57 <sgothel> @Eclesia: Julian only wants to avoid obsoleteness, preserving existing things - don't imply
20141021 12:27:09 <sgothel> I hereby KUDOS French legislation, which seems to jump on that train-wagon as well .. I have read
20141021 12:28:07 <sgothel> (even if it means that you need to pay >= 1000 EUR for a laundry machine, compared to 200 EUR for a throw-away one :)
20141021 12:29:01 <sgothel> in the end, this hopefully would generate even more jobs - i.e. reinstate them (repair, etc)
20141021 12:30:38 <sgothel> however .. I would not write an engine for FFP these days, sure - but keep existing things working: why not?
20141021 12:43:15 <gouessej> this is what I do, I keep things working
20141021 12:43:32 <gouessej> but obviously some things are too difficult to implement without shaders
20141021 12:44:52 <gouessej> If we already had a Swing-like API supporting JogAmp, I would be happy to throw AWT into the trashbin
20141021 12:44:54 * doev (~doev@anon) Quit (Quit: Verlassend)
20141021 12:45:19 <sgothel> you mean UI, will happen ..
20141021 12:46:50 <eclesia> Is happening...
20141021 12:47:08 <sgothel> it is funny how the whole Debian systemd discussion leads to exclude all non-Linux platforms (by pro-and-exclusive-systemd folks), once it was a kernel agnostic highly portable system.
20141021 12:48:44 <sgothel> hehe .. well let us say, many GL UI solutions already exist, incl. experimental Graph-UI
20141021 12:49:46 <sgothel> (and UN, and NiftyGUI .. etc)
20141021 12:49:47 <eclesia> I have completely separate my layout api from widgets, easier to reuse and copy if you want it ^^
20141021 12:50:06 <sgothel> great, thank you
20141021 12:50:20 <sgothel> does it allow layout based on DPI ?
20141021 12:51:02 <sgothel> i.e. fixed sized elements (w/ min- and max size), as well as relative position based on layout
20141021 12:51:13 <sgothel> i.e. size may vary as well within some reasonable bounds
20141021 12:51:33 <sgothel> guess have to also check xml/html renderer
20141021 12:51:34 <eclesia> dpi is out of the layout scope. Positionable has size informations, layout has a view bbox. and that's all he needs. the positionable ake care of the dpi by adjusting their size
20141021 12:52:03 <eclesia> I'll give you the link this evening
20141021 12:52:18 <sgothel> thx .. so, sort of 'yes, dpi is taken into consideration'
20141021 12:54:47 <gouessej> I need something that could be used to port existing Swing applications
20141021 12:55:44 <gouessej> it would have a lot of success in scientifical visualization
20141021 12:55:51 <gouessej> in CAD softwares too
20141021 12:56:26 <gouessej> and you see which kind of machines some customers have :s
20141021 12:56:45 <gouessej> OpenGL 1.1 or 1.4 sometimes
20141021 12:57:19 <gouessej> :s If I come with a shader based UI framework, it will be less appealing
20141021 12:58:45 <gouessej> That's why I insist on the robustness even with crappy drivers
20141021 12:59:29 <gouessej> Imagine a customer who just gets a crash with nothing because there is no way to display a widget as JOGL can't get initialized :s
20141021 12:59:57 <sgothel> well, Graph-UI will be shader based, since we cannot implement it using the GPU otherwise (see paper)
20141021 13:00:20 <gouessej> yes I know why, I understand the problem
20141021 13:03:16 <gouessej> I already tried to draw lines without GL_LINES
20141021 13:03:33 <gouessej> fixed size lines
20141021 13:03:43 <gouessej> what a nightmare
20141021 13:03:59 <sgothel> lines curves, and picking color from texures ofc (see our applet Graph-UI demo)
20141021 13:05:13 <gouessej> He uses shaders to do that: https://www.mapbox.com/blog/drawing-antialiased-lines/
20141021 13:05:45 <gouessej> I don't know yet how to do the same without shaders
20141021 13:06:09 <sgothel> I know and discussed it w/ Jens (Nifty) .. tried it, however - it is not feasible for text and small geometry
20141021 13:06:36 <sgothel> here .. we need to use our VBAA (view based AA using an FBO)
20141021 13:06:50 <sgothel> if dpi < 200 (round about)
20141021 13:07:36 <gouessej> What do you mean by "it is not feasible"? I expect to find a solution even though the performance will be worse than a shader based solution
20141021 13:07:53 <sgothel> feasible == could not find a solution
20141021 13:08:16 <gouessej> ok
20141021 13:08:36 <sgothel> many papers do state this - its basically due to high frequency signals to be reduced while removing the aliasing (AA)
20141021 13:08:53 <sgothel> and especially if geometries are mixed .. you cannot
20141021 13:09:29 <sgothel> yes, I was able to render one diagonal AA line w/ such algos .. but can't do w/ complex geometry
20141021 13:12:24 <gouessej> Lol they copied a part of LibGDX to have a common API: https://github.com/opensciencemap/vtm/blob/037c25153ba199769b0dd214c90b65e3817516c9/vtm/src/org/oscim/backend/GL20.java
20141021 13:16:20 <gouessej> Some libraries have probably already solved this problem, maybe Cairo
20141021 13:17:06 <sgothel> within their realms yes - BUT they use CPU based font AA, sub-pixel, as well as grid-fitting
20141021 13:17:32 <sgothel> for high performance text [animations] we cannot apply grid fitting (we have no grid) ..
20141021 13:18:17 <sgothel> and anything like such raster optimization would require us to produce new graph curves for each position -> very low performance
20141021 13:18:36 <gouessej> Cairo has an OpenGL backend
20141021 13:18:51 <sgothel> yes, but not for font rendering
20141021 13:19:15 <sgothel> freetype <- they all use
20141021 13:19:49 <sgothel> if you solved font rendering on GPU, you can do anything - it's *king*
20141021 13:22:19 <gouessej> I look at this thing for now: http://tyt2y3.github.io/vaser-web/
20141021 13:24:14 <sgothel> yes, tesselation of poles etc .. same method as the http://lii-enac.fr/en/projects/istar/
20141021 13:24:23 <sgothel> font ? doesn't work
20141021 13:28:34 <gouessej> I think that I will have to read a lot more papers about this subject
20141021 13:28:54 <gouessej> Google refused my RFE + patch on Guava :(
20141021 13:30:08 <gouessej> https://code.google.com/p/guava-libraries/issues/detail?id=1845
20141021 13:31:44 <sgothel> http://www.cg.tuwien.ac.at/research/publications/2012/ROESSLER-2012-OGLES/ <- this was the paper for AA lines
20141021 13:37:36 <sgothel> ^^ based on a paper on McNamara et al. see [18]
20141021 13:42:14 <sgothel> http://people.csail.mit.edu/ericchan/articles/prefilter/ http://fileadmin.cs.lth.se/graphics/research/papers/masses2003/ http://fileadmin.cs.lth.se/graphics/research/papers/inexp_ms2005/
20141021 13:42:24 <sgothel> (general AA ..)
20141021 13:42:35 <sgothel> multi-sampling ..
20141021 13:43:08 <sgothel> CDTriangulator2DExpAddOn <- partially impl. ROESSLER-2012-OGLES
20141021 13:57:55 <sgothel> http://www.lucas-nussbaum.net/blog/?p=845 <- init/systemd dependency discussion https://lists.debian.org/debian-vote/2014/10/threads.html#00001
20141021 13:58:07 <sgothel> https://lists.debian.org/debian-vote/2014/10/msg00279.html
20141021 14:07:48 <gouessej> I didn't understand his code, he still uses glLineWidth(), etc...
20141021 14:11:29 <gouessej> Istar looks like a project of VVM lead by some of my former teachers at Paris 6
20141021 14:16:16 <sgothel> AFK .. laters
20141021 14:22:32 <gouessej> Ok bye
20141021 14:37:23 * darkfrog (~mhicks@anon) has joined #jogamp
20141021 14:37:40 <darkfrog> does JOGL override the java.library.path?
20141021 14:38:37 <gouessej> darkfrog: I can check if you want
20141021 14:39:22 <gouessej> darkfrog: If you really want it not to override the Java library path, disable the automatic extraction and loading of native libraries
20141021 14:39:23 <darkfrog> gouessej: that would be appreciated....I'm trying to set the java.library.path for another native library and (on Windows specifically) it doesn't seem to be able to pick it up.
20141021 14:39:34 <darkfrog> how do I do that?
20141021 14:39:46 <gouessej> it's in the userguide... Wait for a minute
20141021 14:40:20 <gouessej> darkfrog: -Djogamp.gluegen.UseTempJarCache=false
20141021 14:40:37 <darkfrog> gouessej: thanks. :)
20141021 14:40:53 <darkfrog> just switched from LWJGL to JOGL and there does seem to be a performance improvement
20141021 14:41:10 <gouessej> darkfrog: use it carefully, you have to set the Java library path by yourself with JOGL and GlueGen native files then
20141021 14:41:32 <gouessej> darkfrog: it is a good piece of news
20141021 14:42:18 <darkfrog> thanks. :)
20141021 14:42:22 <gouessej> darkfrog: I'm almost sure we don't modify the Java library path, we tell Java exactly where the native library is located
20141021 14:42:46 <darkfrog> gouessej: well, on Windows something strange is happening
20141021 14:42:55 <darkfrog> it seems to work fine on Linux and Mac
20141021 14:43:08 <gouessej> darkfrog: we'll find the culprit as usual
20141021 14:43:13 <darkfrog> :)
20141021 14:43:21 <darkfrog> we're still digging as well
20141021 14:43:51 <gouessej> you should display the Java library path at runtime
20141021 14:44:00 <darkfrog> we're writing a MediaCenter in Scala + JOGL + VLC and the MVP should be posted on Kickstarter by the end of the year. I'll share the link when we get there.
20141021 14:44:19 <gouessej> good job
20141021 14:44:34 <gouessej> ok I check in GlueGen
20141021 14:44:49 <darkfrog> gouessej: did you used to be on jME?
20141021 14:45:52 <gouessej> darkfrog: I used JMonkeyEngine for more than a year and I still maintain the JOGL backend of JMonkeyEngine 3. I maintain JogAmp's Ardor3D Continuation too, I help sometimes on Java 3D, LibGDX, ...
20141021 14:46:16 <darkfrog> Java3D still exists?
20141021 14:46:20 <gouessej> yes
20141021 14:46:24 <darkfrog> I thought it died years ago
20141021 14:46:57 <gouessej> I resurrected it years ago and Harvey did a huge job on it, fixed tons of bugs, fixed the build scripts, ...
20141021 14:47:06 <darkfrog> interesting
20141021 14:47:13 <gouessej> but please don't use it :)
20141021 14:47:21 <darkfrog> hehe, I have no intention of doing so. :-p
20141021 14:47:34 <gouessej> It's frozen, in maintenance mode
20141021 14:47:42 <darkfrog> I've been away from the JVM scenegraph world for a while now
20141021 14:48:32 <darkfrog> after creating and then abandoning my own 3d engine in Scala (http://www.sgine.org/) I haven't really been back except to write a few things in libgdx until now
20141021 14:49:34 <gouessej> ok
20141021 14:49:45 <gouessej> Do you use our backend with LibGDX?
20141021 14:51:15 <darkfrog> for the mediacenter we're just using JOGL straight
20141021 14:52:00 <gouessej> ok
20141021 14:52:29 <gouessej> Your answer is in this class, we don't even use System.load(): https://github.com/sgothel/gluegen/blob/master/src/java/com/jogamp/common/os/NativeLibrary.java
20141021 14:53:19 <gouessej> I have to look at the C code too
20141021 14:53:20 <darkfrog> hmmm....then I wonder why Windows is being a pain
20141021 14:57:53 <gouessej> https://github.com/sgothel/gluegen/blob/master/src/java/jogamp/common/os/WindowsDynamicLinkerImpl.java
20141021 14:58:33 <gouessej> it uses LoadLibraryW
20141021 14:59:55 <darkfrog> gouessej: thanks for checking for me, I appreciate it
20141021 15:00:24 <gouessej> darkfrog: You're welcome. We are here to help
20141021 15:04:27 <gouessej> darkfrog: If the default behaviour doesn't satisfy you, look at how we could use LoadLibraryEx instead but I'm very skeptical
20141021 15:05:28 * eclesia (~husky@anon) has left #jogamp
20141021 15:46:23 <gouessej> hharrison: Sorry to disturb you, have you looked at the bug 1090?
20141021 15:46:55 <gouessej> hharrison: https://jogamp.org/bugzilla/show_bug.cgi?id=1090
20141021 15:52:48 * rmk0 (~rmk0@anon) Quit (Ping timeout: 260 seconds)
20141021 16:01:02 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141021 16:05:04 * gouessej (5ee4b442@anon) Quit (Quit: Page closed)
20141021 16:20:23 * Eclesia (~eclesia@anon) has joined #jogamp
20141021 16:23:02 <Eclesia> sgothel: https://bitbucket.org/Eclesia/unlicense/src/tip/api/api-display/src/main/java/un/api/layout/?at=default
20141021 16:25:10 <Eclesia> there are still a few things I'm not satisfied with (like how to indicate grow direction : multiline labels or text areas) but otherwiser I think it is a good design
20141021 16:25:23 <Eclesia> -r
20141021 16:36:48 * monsieur_max (~maxime@anon) has joined #jogamp
20141021 17:23:42 * rmk0 (~rmk0@anon) has joined #jogamp
20141021 17:23:42 * rmk0 (~rmk0@anon) Quit (Changing host)
20141021 17:23:42 * rmk0 (~rmk0@anon) has joined #jogamp
20141021 17:37:55 <hharrison> sgothel: where's the best place to serve the Java3D javadocs out of on jogamp?
20141021 17:38:13 <hharrison> Julien just pinged me about bug 1090
20141021 17:54:17 <hharrison> sgothel: have you ever seen the code in the kernel under CONFIG_VT....there's a reason I'm looking forward to the userspace console stuff
20141021 17:54:39 <hharrison> The fact that the people doing that work want to do it under the systemd project bothers me not-at-all
20141021 18:16:34 * gouessej (5279497b@anon) has joined #jogamp
20141021 18:17:00 <gouessej> hharrison: There is something else that should be done
20141021 18:19:11 <gouessej> hharrison: it would be nice to upload an archive with the JARs
20141021 18:19:29 <hharrison> like a -src archive?
20141021 18:19:40 <hharrison> Or what do you mean?
20141021 18:19:54 <gouessej> hharrison: because Firefox under Windows breaks the JARs :(
20141021 18:20:12 <gouessej> hharrison: just a .7z archive with all JARs like for jogamp
20141021 18:21:00 <hharrison> ahhh
20141021 18:21:12 <gouessej> hharrison: Firefox wraps each JAR into a ZIP archive
20141021 18:21:51 <gouessej> hharrison: I have no right on this directory, it's quite easy to do
20141021 18:24:46 <gouessej> hharrison: I can check that...
20141021 18:27:24 <gouessej> sgothel: I need the write access on deployment/java3d
20141021 18:29:14 <gouessej> hharrison: Maybe you can change the right access except if you change to make the archive by yourself
20141021 18:29:26 <gouessej> "if you want to make"
20141021 18:31:37 <hharrison> Yeah, I can go in and do it this afternoon
20141021 18:31:58 <hharrison> the archive and the write access
20141021 18:32:35 <gouessej> thanks
20141021 18:32:50 <gouessej> What does it mean "this afternoon"? There is a time shift
20141021 18:33:38 <gouessej> Please can you put the JARs into the "jar/" directory like for jogamp-all-platforms.7z?
20141021 18:34:05 <gouessej> That way, we will be able to add other things later if necessary without adding any confusion
20141021 18:34:14 <gouessej> changelogs, release notes
20141021 18:34:18 <gouessej> license
20141021 18:34:22 <gouessej> readme
20141021 18:34:50 <hharrison> Sometime in the next 4-5 hours
20141021 18:34:57 <hharrison> I have a meeting to step out to
20141021 18:35:06 <gouessej> Ok thanks
20141021 18:37:07 <gouessej> I will have to do the same for JogAmp's Ardor3D Continuation
20141021 18:46:12 * rmk0 (~rmk0@anon) Quit (Ping timeout: 250 seconds)
20141021 19:09:37 <sgothel> @Harvey: http://jogamp.org/deployment/java3d/<release-version>/javadoc/<module>/ http://jogamp.org/deployment/java3d/1.6.0-pre11/javadoc/j3dcore/
20141021 19:09:46 <sgothel> similar to jogl ..
20141021 19:09:56 <sgothel> http://jogamp.org/deployment/v2.2.4/javadoc/jogl/javadoc/
20141021 19:10:59 <sgothel> @Harvey: a '-src' archive file would surely be nice for IDEs as well
20141021 19:11:25 <sgothel> @Harvey re: systemd: All good - it would only bother me if enforced - thats the whole point
20141021 19:11:44 * rmk0 (~rmk0@anon) has joined #jogamp
20141021 19:11:44 * rmk0 (~rmk0@anon) Quit (Changing host)
20141021 19:11:44 * rmk0 (~rmk0@anon) has joined #jogamp
20141021 19:14:32 <sgothel> @harvey: so I add Julien to the group java3d ? Julien: Is this right ?
20141021 19:14:38 <gouessej> yes
20141021 19:15:24 <sgothel> you are in java3d now
20141021 19:16:07 <gouessej> thanks
20141021 19:17:14 <gouessej> j3d.7z?
20141021 19:17:17 <gouessej> good name?
20141021 19:20:12 <sgothel> puh .. how about jogamp-java3d.7z ?
20141021 19:31:11 <gouessej> ok
20141021 19:39:39 * rmk0 (~rmk0@anon) Quit (Ping timeout: 258 seconds)
20141021 20:06:31 <gouessej> sgothel: permission denied
20141021 20:07:39 <sgothel> drwxrwxr-x 9 jogamp java3d /srv/www/jogamp.org/deployment/java3d
20141021 20:07:46 <gouessej> sgothel: the subdirectory 1.6.0-pre11 has Harvey as an owner
20141021 20:07:51 <gouessej> :s
20141021 20:08:18 <sgothel> done
20141021 20:08:56 <gouessej> still permission denied, I'm checking on my side
20141021 20:09:48 <hharrison> java3d-pre11.7z
20141021 20:10:06 <sgothel> fixed
20141021 20:11:46 <gouessej> Harvey and Sven, which name should I use then? jogamp-java3d.7z (done) or java3d-pre11.7z?
20141021 20:11:56 <gouessej> java3d-pre11.7z is a bit reduntant
20141021 20:12:42 <hharrison> But when someone downloadis it, they get a bit more context on their local copy
20141021 20:12:48 <hharrison> I'm indifferent really
20141021 20:12:49 * rmk0 (~rmk0@anon) has joined #jogamp
20141021 20:12:49 * rmk0 (~rmk0@anon) Quit (Changing host)
20141021 20:12:49 * rmk0 (~rmk0@anon) has joined #jogamp
20141021 20:13:07 <gouessej> j3dcore doesn't indicate which version it is
20141021 20:13:20 <hharrison> yeah...just noticed I skipped that :-O
20141021 20:13:30 <gouessej> I keep jogamp-java3d.7 but feel free to change that
20141021 20:13:38 <hharrison> that's fine
20141021 20:13:45 <gouessej> Just drop me an email if you modify the name so that I update my tutorial
20141021 20:20:39 <gouessej> Now, some newbies won't get broken JARs, it's better :)
20141021 20:22:44 <gouessej> hharrison: You haven't told me your opinion about the possibility to provide a JAR with renamed packages for Java 3D so that we don't break the public API but we skip obsolete versions for "those who know"
20141021 20:23:49 <hharrison> For Java3d, kinda thinking it would be best to just leave it as it is really
20141021 20:24:19 <gouessej> Ok but my workaround to skip the extensions doesn't always work :s
20141021 20:24:24 <hharrison> The OSX thing is a bit of a pain though
20141021 20:24:41 <gouessej> yes
20141021 20:24:53 <gouessej> most of the "troubleshooting" section is for OS X
20141021 20:25:12 <hharrison> Best may be to get apple to stop shipping java3d with their java, or update to 1.6
20141021 20:25:43 <gouessej> JogAmp only supports OpenJDK and Oracle Java under OS X
20141021 20:25:43 <hharrison> Not sure who at oracle/apple even looks after their java distribution these days
20141021 20:29:16 <gouessej> Apple may refuse to stop shipping this crap anyway
20141021 20:49:29 * gouessej (5279497b@anon) Quit (Quit: Page closed)
20141021 20:58:41 <Eclesia> good night +++
20141021 20:58:54 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20141021 21:13:24 <sgothel> "(10:25:43 PM) gouessej: JogAmp only supports OpenJDK and Oracle Java under OS X" <- Nope, works on Apple's JVM as well
20141021 21:13:51 <sgothel> release 2.2.4 has OSX 32bit re-enabled
20141021 21:32:24 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141022 05:06:24 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20141022050624.html