Re: [josm-dev] Fwd: GSoC: OpenGL view for JOSM
On 23.03.2015 17:32, Michael Zangl wrote: Hi, Thanks for the comment. The main problem I have with the Icons is the packing. I don't want to use a single texture for every icon, since a texture switch is expensive. Can't be that bad. Better start with something simple but working and leave complicated optimizations for later. Using GLG2D is a good idea. I might just add that for all unsupported layers. Although I cannot add it for drawing unsupported things on the OSM layer, it should make most plugins compatible with OpenGL. I wouldn't rely on it too much yet (without testing). There can be all kinds of complications with this library. Drawing Swing components on top of JOGL and the other way around is an option I don't like, since it went wrong the last time I tried it (mouse events not beeing captured correctly, ...). Could you report the problem to JOGL, so they can fix it in the meantime (or offer a workaround)? But it might also just need some more tweaking. Or that. :) Best, Paul ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Fwd: GSoC: OpenGL view for JOSM
On 17.03.2015 11:41, Michael Zangl wrote: Thanks for the feedback on my idea. Based on the feedback and the tests I made the past few days, I wrote a GSoC application. http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/michaelz/5750085036015616 Feel free to leave feedback/your thoughts on this. The comment section on the Melange platform doesn't seem to be public, so I post it here again: Nice application! I'm all for setting realistic, achievable goals. But I was impressed, how much you could do in a small time, and hoped, you would aim for a full (or nearly full) replication of the Java2D rendering. A display without icons is kind of pointless, we don't need another Wireframe mode! Also, the text along line feature is an integral part of the standard style by now, and I wouldn't want to miss it. Keep in mind, that you don't have to implement everything from scratch: As long as you can draw individual letters on screen, it should be possible to build on the existing code for text along line. Yes, this often sounds simpler than it actually is, but you could at least put in on the agenda as a secondary goal. I have looked at your code and was surprised, how complicated it is, to even draw a simple line. This makes me wonder: Have you investigated any higher level libraries, that offer a Java2D-like interface with a JOGL backend? First thing I found was this GLG2D [1]. I know you want to use VBO caching and other low-level techniques, but at least you could copy paste some existing code, to make life easier. Another big issue I have with your proposal, is that you seem to settle with a hard switch between JOGL and Java2D. I.e. either every layer and paint mode must support OpenGL or it isn't used at all. I think this is not really desirable as it restricts the usage a lot. It makes this a toy project and technology show-off, when it could be a general turbo mode that just works for basically every user (with fairly modern hardware). You should investigate, how this can be fixed (can be during the work period). One option would be a Java2D-JOGL bridge like GLG2D. Alternatively, it seems to be possible to mix JOGL and Java2D in certain ways [2]. What are the performance implications? If you come to the conclusion, that it is not possible at all, this is fine, but the results should be documented properly. [1] https://github.com/brandonborkholder/glg2d [2] http://www.java-gaming.org/index.php?topic=10813.0 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Fwd: GSoC: OpenGL view for JOSM
Hi, Thanks for the comment. The main problem I have with the Icons is the packing. I don't want to use a single texture for every icon, since a texture switch is expensive. This can be solved, I already did that in jsettlers and can probably copy some code. The main problem would be to find the icons to pack together on a texture. Icon drawing is already in the current code (if there was a texture present, you could just draw a quad and supply UV coordinates). I also have not yet looked at the text-along-line feature. If it is that simple, I will add it. I never did rotated text with JOGL. Changing the rotation matrix for every call is expensive and JOGL does not expose it's backing texture. So we might need to copy some of JOGLs text drawing (which is basically to use Java2D to draw the text onto a texture and then use that texture on the screen). That way, we could use VBOs, get a really fast text drawing and can rotate every letter as we want to. Using GLG2D is a good idea. I might just add that for all unsupported layers. Although I cannot add it for drawing unsupported things on the OSM layer, it should make most plugins compatible with OpenGL. Drawing Swing components on top of JOGL and the other way around is an option I don't like, since it went wrong the last time I tried it (mouse events not beeing captured correctly, ...). But it might also just need some more tweaking. Michael Am 23.03.2015 um 15:19 schrieb Paul Hartmann: On 17.03.2015 11:41, Michael Zangl wrote: Thanks for the feedback on my idea. Based on the feedback and the tests I made the past few days, I wrote a GSoC application. http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/michaelz/5750085036015616 Feel free to leave feedback/your thoughts on this. The comment section on the Melange platform doesn't seem to be public, so I post it here again: Nice application! I'm all for setting realistic, achievable goals. But I was impressed, how much you could do in a small time, and hoped, you would aim for a full (or nearly full) replication of the Java2D rendering. A display without icons is kind of pointless, we don't need another Wireframe mode! Also, the text along line feature is an integral part of the standard style by now, and I wouldn't want to miss it. Keep in mind, that you don't have to implement everything from scratch: As long as you can draw individual letters on screen, it should be possible to build on the existing code for text along line. Yes, this often sounds simpler than it actually is, but you could at least put in on the agenda as a secondary goal. I have looked at your code and was surprised, how complicated it is, to even draw a simple line. This makes me wonder: Have you investigated any higher level libraries, that offer a Java2D-like interface with a JOGL backend? First thing I found was this GLG2D [1]. I know you want to use VBO caching and other low-level techniques, but at least you could copy paste some existing code, to make life easier. Another big issue I have with your proposal, is that you seem to settle with a hard switch between JOGL and Java2D. I.e. either every layer and paint mode must support OpenGL or it isn't used at all. I think this is not really desirable as it restricts the usage a lot. It makes this a toy project and technology show-off, when it could be a general turbo mode that just works for basically every user (with fairly modern hardware). You should investigate, how this can be fixed (can be during the work period). One option would be a Java2D-JOGL bridge like GLG2D. Alternatively, it seems to be possible to mix JOGL and Java2D in certain ways [2]. What are the performance implications? If you come to the conclusion, that it is not possible at all, this is fine, but the results should be documented properly. [1] https://github.com/brandonborkholder/glg2d [2] http://www.java-gaming.org/index.php?topic=10813.0 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Fwd: GSoC: OpenGL view for JOSM
Hi everyone, Thanks for the feedback on my idea. Based on the feedback and the tests I made the past few days, I wrote a GSoC application. http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/michaelz/5750085036015616 Feel free to leave feedback/your thoughts on this. Regards, Michael Am 09.03.2015 um 18:19 schrieb Michael Zangl: Hi, I'm also posting this on the JOSM-List in hope to get feedback on the technical parts here. Regards, Michael Weitergeleitete Nachricht Betreff: [OSM-dev] GSoC: OpenGL view for JOSM Datum: Mon, 09 Mar 2015 13:58:41 +0100 Von: Michael Zangl openstreet...@michael.fam-zangl.net An: d...@openstreetmap.org Hello, This is a thing that annoyed me for a long time: JOSM is slow when zooming out. I would like to improve this and have enough spare time this summer to work on this as GSoC project. I am currently studying computer science at the KIT (Karlsruhe, Germany). My OSM name is michael2402. Motivation Currently, JOSM uses the default Java 2D framework. While this is portable (it just works) and also supports 2d graphic acceleration using OpenGL, it is not as fast as a plain OpenGL implementation would be. This is why I would suggest adding a second render mode to JOSM which would then use OpenGL and all it's modern features like VBOs to accelerate rendering and allow a smooth moving of a zoomed-out map. The idea: I would like to add a second rendering mode that only uses OpenGL. Users are then able to chose between classic rendering and the new OpenGL render styles. The basic idea is that this interface can be used if you want to work in an urban area with a lot of details and change e.g. the public transport system so you need to zoom out a lot. The current renderer is pretty slow as soon as there are many objects in the view. Therefore, even a not-fully-featured Renderer can be beneficial for users to get an overview over the area. I would then add a new rendering interface that exposes the new features required/provided by OpenGL. That interface should be prepared to accept 3D-Positions (although I don't plan on using them, but maybe someone might want to add shadows or even a real 3D building view in the future). We have to discuss how this works, but currently I am in favor of offsetting all nodes to the ground elevation (so a barrier=wall might be from 0 to 1 meter), then adding the elevation we got from elevation tags (ele, NASA data, ...) That rendering interface can then be used by plugins to add their own styles. This would be necessary if one wanted to add real 3D objects, like trees. This is more like a bonus feature, so I will be writing a test plugin to test the interface. We also need a way to add ground (= Background) images for background layers. I would then create one plugin that can uses MapCSS to render a style in the view. That way, many existing styles can be used with the new interface. This will be the most part of the work on this project. As library I would currently prefer JOGL, since I already have experience with it and it contains some additional features we would need (like text rendering support and the ability to be added as swing panel). Current status: - Currently, each layer draws it self to the Java Graphics. Most layers are not really extensible (like the GPX-Track feature), which makes it hard to modify them using plugins (like adding non-standard accuracy info to GPX and drawing the accuracy area instead of the line). - Layers are drawn the way they are ordered in the side view. - There are basically two types of layers: Background layers (ImageryLayer.java, TMSLayer.java, ...) and data layers (GpxLayer.java, OsmDataLayer.java, ...) Implementation details/ideas (so far): - JOSM create a list of Drawer objects for each layer. - I would like to use a 2D plane (which can then be offsetted using shaders) to be the background for all of the map. There is only one background pane with the textures of background layers added to it. I will have to look more into shaders (like supporting an unlimited number of textures on a single area) but I hope this is possible. -- Fallback: Just render the images as rectangle, one over the other, using opacity settings and disabling the depth buffer (the way it is done currently). Cache using VBOs. This is not as modern as shaders would be, but it is simple. - Layers make heavy use of VBOs. I would like to provide a nice interface to draw and cache VBO structures. This will also speed up drawing of the map a lot, since the map does not change. Thinks it should do include: -- Draw a point at the given lat/lon -- Draw a line of width x with given (lat/lon/width) point pairs and color, closed or open. -- Draw a filled area (without contour) -- Add text at a given position. -- MapCSS properties this basically supports: width, color (rgba), dashes, linecap, linejoin, fill-color
Re: [josm-dev] Fwd: GSoC: OpenGL view for JOSM
On Mon, Mar 9, 2015 at 10:19 AM, Michael Zangl openstreet...@michael.fam-zangl.net wrote: This is a thing that annoyed me for a long time: JOSM is slow when zooming out. I would like to improve this and have enough spare time this summer to work on this as GSoC project. One reason is fairly simple to fix: JOSM loads background image tiles in a non-optimal order. If it first loaded the tiles under the currently selected object and the mouse cursor, it would feel much faster. As it stands often the map tiles that are half off screen come in first. ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Fwd: GSoC: OpenGL view for JOSM
Hi, I'm also posting this on the JOSM-List in hope to get feedback on the technical parts here. Regards, Michael Weitergeleitete Nachricht Betreff: [OSM-dev] GSoC: OpenGL view for JOSM Datum: Mon, 09 Mar 2015 13:58:41 +0100 Von: Michael Zangl openstreet...@michael.fam-zangl.net An: d...@openstreetmap.org Hello, This is a thing that annoyed me for a long time: JOSM is slow when zooming out. I would like to improve this and have enough spare time this summer to work on this as GSoC project. I am currently studying computer science at the KIT (Karlsruhe, Germany). My OSM name is michael2402. Motivation Currently, JOSM uses the default Java 2D framework. While this is portable (it just works) and also supports 2d graphic acceleration using OpenGL, it is not as fast as a plain OpenGL implementation would be. This is why I would suggest adding a second render mode to JOSM which would then use OpenGL and all it's modern features like VBOs to accelerate rendering and allow a smooth moving of a zoomed-out map. The idea: I would like to add a second rendering mode that only uses OpenGL. Users are then able to chose between classic rendering and the new OpenGL render styles. The basic idea is that this interface can be used if you want to work in an urban area with a lot of details and change e.g. the public transport system so you need to zoom out a lot. The current renderer is pretty slow as soon as there are many objects in the view. Therefore, even a not-fully-featured Renderer can be beneficial for users to get an overview over the area. I would then add a new rendering interface that exposes the new features required/provided by OpenGL. That interface should be prepared to accept 3D-Positions (although I don't plan on using them, but maybe someone might want to add shadows or even a real 3D building view in the future). We have to discuss how this works, but currently I am in favor of offsetting all nodes to the ground elevation (so a barrier=wall might be from 0 to 1 meter), then adding the elevation we got from elevation tags (ele, NASA data, ...) That rendering interface can then be used by plugins to add their own styles. This would be necessary if one wanted to add real 3D objects, like trees. This is more like a bonus feature, so I will be writing a test plugin to test the interface. We also need a way to add ground (= Background) images for background layers. I would then create one plugin that can uses MapCSS to render a style in the view. That way, many existing styles can be used with the new interface. This will be the most part of the work on this project. As library I would currently prefer JOGL, since I already have experience with it and it contains some additional features we would need (like text rendering support and the ability to be added as swing panel). Current status: - Currently, each layer draws it self to the Java Graphics. Most layers are not really extensible (like the GPX-Track feature), which makes it hard to modify them using plugins (like adding non-standard accuracy info to GPX and drawing the accuracy area instead of the line). - Layers are drawn the way they are ordered in the side view. - There are basically two types of layers: Background layers (ImageryLayer.java, TMSLayer.java, ...) and data layers (GpxLayer.java, OsmDataLayer.java, ...) Implementation details/ideas (so far): - JOSM create a list of Drawer objects for each layer. - I would like to use a 2D plane (which can then be offsetted using shaders) to be the background for all of the map. There is only one background pane with the textures of background layers added to it. I will have to look more into shaders (like supporting an unlimited number of textures on a single area) but I hope this is possible. -- Fallback: Just render the images as rectangle, one over the other, using opacity settings and disabling the depth buffer (the way it is done currently). Cache using VBOs. This is not as modern as shaders would be, but it is simple. - Layers make heavy use of VBOs. I would like to provide a nice interface to draw and cache VBO structures. This will also speed up drawing of the map a lot, since the map does not change. Thinks it should do include: -- Draw a point at the given lat/lon -- Draw a line of width x with given (lat/lon/width) point pairs and color, closed or open. -- Draw a filled area (without contour) -- Add text at a given position. -- MapCSS properties this basically supports: width, color (rgba), dashes, linecap, linejoin, fill-color (rgba), font-size, text-color, text-offset, text. -- What we won't support: z-index (but we could order the elements before drawing), casing, extrude, icons, text-position. - Each VBO is tied to map objects that it depends on. That way, it only needs to be updated if those objects change. Doing this is done by the renderer (which also has knowledge of all MapCSS styles). -- The MapCSS renderer needs to be adjusted to keep track of object
