rendering pipeline

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

rendering pipeline

moovida
Can anyone give me a hint about where rendering occurrs and if there might be a way to extract the module and use it in  different environment?
Any hint for an entrypoint is appreciated :)

Thanks,
Andrea
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: rendering pipeline

Alexis.G
Le 20/01/2012 17:20, moovida [via OrbisGIS] a écrit :
> Can anyone give me a hint about where rendering occurrs and if there
> might be a way to extract the module and use it in  different
> environment?
> Any hint for an entrypoint is appreciated :)
>

*NOTE* : that will probably  be my last answer before monday... I hope
to sleep some time this week-end :-p

Rendering is currently made by orbisgis-core. This library is dedicated
to the management of layers and legend, and is responsible to the
drawing operations. Some information before going further...

This layer is dependent upon GDMS and GDMSQL. This second library
contains all the needed codes to let us handle datasources through the
SQL language. It's not used much in orbisgis-core, but there should be
some places where it is needed. However, the classes that seem to be
used (SQLDataSourceFactory and FilterDataSourceDecorator) are quite
important for the renderer to work properly... There is some work to do,
so ^_^

A problem might appear here. Indeed, we have developed large parts of
gdmsql using scala rather than Java. Indeed, it permits us to be more
concise and clearer while describing the behaviour of our SQL
implementation. I'm not sure, though, that it will be easy to compile
these codes for the android platform. I know some projects exist, but as
I've said before, I've never worked on Dalvik...

There should be some strategies to get rid off this problem. But to
choose the best one, I think we need to know what goal you're trying to
achieve ;-)

Good evening,

Alexis.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: rendering pipeline

Alexis.G
Hi,

I certainly can be more accurate. If we have a look in the package that makes the rendering operations, we have only a few dependencies against the gdmsql library. Indeed, the only missing class is SQLDataSourceFactory. (I've mentioned SQLDataSourceDecorator... It's used in the new renderer I'm working on, but not in the trunk's renderer).

The algorithm used to draw the geometries is located in the class Renderer. It is abstract, but mots of the intelligence is here. I think you'll be particularly interested in drawVectorLayer and draw operations.

These methods are applied on Layer instances. A Layer is basically a data source that comes along with some styling property. It is contained in a layer model, that let us decide in which order we will draw the layers. Nothing extraordinary, so ;-)

The algorithms deeply use AWT. It is the standard way to handle images on the JVM. Don't know if it can be used on Dalvik...

Note that we are speaking about the current renderer contained in the trunk. But we working to abandon it. I am actively working on a new rendering library, that is based on some OGC standards (SE, OWC, FES...). The way we decorate layers deeply change, so there is a deep work on the rendering algorithms...

Regards,

Alexis.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: rendering pipeline

moovida
Hi Alexis,
I spend the weekend in trying to port the orbisgis core package in order to have the layering system in and android project and have it rendering on a View's Canvas.
The Renderer class is the only one left with errors right now :)


Alexis.G wrote
I certainly can be more accurate. If we have a look in the package that makes the rendering operations, we have only a few dependencies against the gdmsql library. Indeed, the only missing class is SQLDataSourceFactory. (I've mentioned SQLDataSourceDecorator... It's used in the new renderer I'm working on, but not in the trunk's renderer).
Well, the SQLDataSourceFactory is something I had to get ridd of to get started.
Why is that one directly referenced instead of its interface?

Alexis.G wrote
The algorithm used to draw the geometries is located in the class Renderer. It is abstract, but mots of the intelligence is here. I think you'll be particularly interested in drawVectorLayer and draw operations.
That is good to know, thanks, I'll check into it.

<quote author="Alexis.G">
These methods are applied on Layer instances. A Layer is basically a data source that comes along with some styling property. It is contained in a layer model, that let us decide in which order we will draw the layers. Nothing extraordinary, so ;-)

The algorithms deeply use AWT. It is the standard way to handle images on the JVM. Don't know if it can be used on Dalvik...
<quote>

No, that is the really aching point. The AWT parts have to be substituted, which makes the work so hard. The same applied to the ImageJ parts, since that one also bases on awt.

Alexis.G wrote
Note that we are speaking about the current renderer contained in the trunk. But we working to abandon it. I am actively working on a new rendering library, that is based on some OGC standards (SE, OWC, FES...). The way we decorate layers deeply change, so there is a deep work on the rendering algorithms...
This last part is scaring me a bit :) So the rendering system is about to change? And with it the whole layer system? Will gdms and grap stay the same?

Thanks,
Andrea


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: rendering pipeline

Alexis.G
moovida wrote
Well, the SQLDataSourceFactory is something I had to get ridd of to get started.
Why is that one directly referenced instead of its interface?
It may just be a design problem. Moreover, as you've certainly noticed, the coupling between gdmsql and the OrbisGIS renderer exists, but is quite low. Consequently, I think we can consider maintaining large parts of GDMS so that it will be usable on Android platforms. Depends on how much it will cost, though.
moovida wrote
Alexis.G wrote
The algorithm used to draw the geometries is located in the class Renderer. It is abstract, but mots of the intelligence is here. I think you'll be particularly interested in drawVectorLayer and draw operations.
That is good to know, thanks, I'll check into it.
It's quite simple. We have a Graphics2D instance. For each geometry, we send the Grahpics2D and the geometry to a Symbol, that paint the geometry in the Graphics2D.

moovida wrote
No, that is the really aching point. The AWT parts have to be substituted, which makes the work so hard. The same applied to the ImageJ parts, since that one also bases on awt.
I suspected this... Unfortunately, it is the most logical way to proceed from our point of view. AWT is the library used to handle image on the standard JVM...

moovida wrote
Alexis.G wrote
Note that we are speaking about the current renderer contained in the trunk. But we working to abandon it. I am actively working on a new rendering library, that is based on some OGC standards (SE, OWC, FES...). The way we decorate layers deeply change, so there is a deep work on the rendering algorithms...
This last part is scaring me a bit :) So the rendering system is about to change? And with it the whole layer system? Will gdms and grap stay the same?
I understand, and that's why I thought it was important to mention it ;-)

GDMS will not deeply change. Indeed, it has already. A very important work of refactoring has been made on it during the past year. And it has been cut into two parts (GDMS, that contains the data management part, and GDMSQL, that contains our SQL language implementation, with all the SQL function defined here).

There are planned modification on it, but it won't break compatibility. The most important thing we must do is to include a new version of the file format, to be able to handle multi-tables schemas, as in any DBMS. But it will just be a new driver, and the older one will be kept.

Grap won't change... it will certainly disappear. There are other libraries in Java that are more powerful and faster. As a GIS, we have to be able to deal properly with large raster dataset. Using something like JAI, for instance the library shipped with BEAM, we would be able to process images of many Go. Using tiles. And that's wonderful. There's already an experimentation, but I must still finish it.

The problem of API won't change, I think. JAI deeply uses ImageIO, and I don't think it is in Dalvik... I don't know if there are common parts, for image management, between the JVM and Dalvik...

The renderer is about to change on the trunk, too. It will occur in two monthes, I think. I have still some work to do on it, to be able to bundle it in a usable OrbisGIS version. And we deeply rely on JAXB... Moreover, using OGC standards, the layer model changes too...

I think you may have arrived just in time. Indeed, I'm not sure OGC standards are designed for mobile applications. It's a bit... heavy, for a smartphone or a tablet. On the other hand, the current architecture can be adapted for the mobile platform. We will certainly be forced to throw away some parts of the software, but I don't think it is a problem.

I'm about to open you an access to our svn and trac. I'll give you some informations in a private e-mail. Don't want to write you password on the interwebs... It will be easier to speak about the code... with the codes under our eyes ;-)

Best wishes,

Alexis.
Loading...