Open 9343d2e0-59ba-4406-bd4f-c78e4cf1230e opened 9 years ago
Commit: 485bdf2
Changed branch from public/3drenders to public/3drenderers
Branch pushed to git repo; I updated commit sha1. New commits:
dd6cdf9 | some fixes, some progress |
+1 to the idea
Its a variant of the translator pattern, so maybe name things JmolTranslator etc?
Branch pushed to git repo; I updated commit sha1. New commits:
4e6a7dc | sphere for tachyon |
Branch pushed to git repo; I updated commit sha1. New commits:
ae8ccb5 | initial idea for rich_repr |
Branch pushed to git repo; I updated commit sha1. New commits:
98873c0 | fix compilation |
Branch pushed to git repo; I updated commit sha1. New commits:
0aeaca6 | fix rich output hopefully |
The idea behind the rich output is that the backend knows best which implementation to pick. The graphics preferences is just to express some overall preference, but it shouldn't be used to micromanage the implementation. E.g. for 2-d graphics there is a choice between raster and vector graphics, but which raster graphics format (png/jpg/gif/...) is intentionally not specified: Which one of those is best depends on the backend capababilities, e.g. the IPython notebook can't display gif. This is also easier for the user since he doesn't have to know the difference between different implementations nor their support in different backends.
For 3-d graphics there is a logical choice between rendered (2-d bitmap) vs live 3d, but shouldn't offer further controls on the particular implementation. More is just confusing to non-experts (what is jmol and why is it not working [if I don't have java installed]?). Let the backend decide what produces good quality and what doesn't.
Right now the preferences that you can set aren't really publicized, so at the moment, non-experts will never really see the preferences. Moreover, I think that you should support experts who might care about the format that they get (e.g. they always want jpg over png) and that they should be able to set their preferences as such.
Additionally, with the binary choice, I wouldn't be able to implement a renderer outside of the sage library and use it as the default in my own backend, since all of the renderers within the sage library would be preferred over my own.
For instance, SMC does not currently use a backend, but rather monkey patches things because it uses its own threejs based renderer. While this stuff will likely eventually make its way into the sage library, you shouldn't be forced to implement these things in the library itself. If the backend can specify its own preferred renderers, then it is possible implement such things outside of the sage library.
Branch pushed to git repo; I updated commit sha1. New commits:
fb1292f | todays progress |
Branch pushed to git repo; I updated commit sha1. New commits:
80067fe | make python stop complaining about indentation |
No, the preferences are what you access through %display
, so they are in fact the easiest and intended way to interact with the display manager. Thats why its user hostile if you name settings after obscure package names, and confusing to boot since not every 3d implementation makes sense for every UI.
If you want to micromanage the format then there is already foo.plot(viewer='jmol')
and friends. The keyword name might/should be changed but at least its hidden away so that no ordinary user has to deal with it. An alternative would be foo.save('output.obj').show()
and use the file extension to guess the type.
You can't realistically have pluggable arbitrary rich output, the author of the Sage object needs to know what the possibilities are in order to decide on the suitable rich output. Now for the the very special case of just 3d graphics that might make sense, but then you can easily do that by
def _rich_repr_:
... try sane defaults first ...
# if none of the defaults work try the rest
for output_type in display_manager.supported_output():
try:
return renderer(self, output_type)
except:
pass
and then declare a particular output type as the only supported one from your backend.
PS: "render" has a rather narrow meaning in the 3d graphics context http://en.wikipedia.org/wiki/3D_rendering, IMHO it would be clearer if you chose a different one
Refactor 3d plotting classes to create a uniform interface for rendering with various frontends. Will make it easier to maintain current and implement new rendering frontends. This will also make it possible to implement a new renderer outside of the Sage library, e.g. for prototyping.
Similar in strategy to rich representation as in #17234.
Note: we use 'render' in the most liberal sense. E.g. x3d "renders" to a particular format. Better term is welcome.
Idea: Instead of a repr method for each renderer on each 3d graphics class, put all rendering commands for a given renderer in a single class. Renderers are registered in a global dict, etc.
To do: Figure out precisely how this should interact with the rich_repr framework.
CC: @ohanar @vbraun @haraldschilly @novoselt
Component: graphics
Keywords: graphics3d, rich_repr
Branch/Commit: public/3drenderers @
c590694
Issue created by migration from https://trac.sagemath.org/ticket/18510