Render panels to graphics files without displaying them first

wxPython Users
1

Is there an easy way to render wxPython panels to file without displaying them on a screen?

Context: We have an interactive application based on wxPython, matplotlib, etc. The interactive application consists of a graphical frontend and a backend server. We have been creating a passive viewer for this application, running on the headless backend, that dumps matplotlib images to graphics files and they get served up by a web server, giving us a simple, portable viewer for the data. The goal is to have the web view mimic the native application as much as possible.

However, some of the things we want to display are currently displayed on wxPython panels (gauge representations of data, for example). As far as I can tell, we can’t create images of the fully rendered panels without actually displaying them on screen. The backend servers are headless, non-interactive, and are not running X11. We don’t really want to display anything on them.

Does anyone have suggestions as to how we can get create images of the wxPanels without displaying them?

Thanks,

Anthony.

2

Is there an easy way to render wxPython panels to file without displaying
them on a screen?

This is a bit of a trick, and may not be possible at all....

Context: We have an interactive application based on wxPython, matplotlib,
etc. The interactive application consists of a graphical frontend and a
backend server. We have been creating a passive viewer for this application,
running on the headless backend, that dumps matplotlib images to graphics
files and they get served up by a web server, giving us a simple, portable
viewer for the data. The goal is to have the web view mimic the native
application as much as possible.

very cool!

However, some of the things we want to display are currently displayed on
wxPython panels (gauge representations of data, for example).

Are these custom-drawn? i.e, with a DC or GC? rather than standard
controls? If so you may be able to draw them to an off-screen bitmap
and go from there. Though I think wx still requires X to be
initialized to use DCs and GCs -- but maybe port then to Cairo or
something?

As far as I
can tell, we can't create images of the fully rendered panels without
actually displaying them on screen.

Particularly if you are using standard controls, yes, that's quite true.

The backend servers are headless,
non-interactive, and are not running X11. We don't really want to display
anything on them.

There is a "dummy" X server, I think it's called Xvfb (virtual frame
buffer). I also see a devbian package called: xserver-xorg-video-dummy

Running that would give you an Xserver that the app would think was
there, but wouldn't require a monitor of video card, or any of the
heavy-weight X stuff.

Though if your goal is to have a desktop and Web UI that are the same,
I'd suggeset a different route:

Do your UI in the browser, then for the desktop version, embed a
browser window in a desktop app. I call this a "Browser Interface,
Local Server" app.

Most (all) of the Python Web frameworks come with a self-contained
http server. You can:

Start up a wxPython app.
start up another thread, and start up your web app in that thread
create a Browser Window in the wxPython app, and point it at your
server (localhost:some_high_port)

This works pretty well, and you can intercept some actions in the web
server, and call into wxPython (with CallAfter, etc) to give the user
a more desktop-like experience, if need be.

There are a few options for embedding a browser window:

- Wrapping the system browser, I think wxHTML2 or somethingn like that works.
- wxWebKit: gives you the WebKit browser component, with wx for display
- Chrome Embedded Framework (PyCEF) -- the full Chrome browser,
embedded in a Pyton app.

HTH,
  -Chris

···

On Mon, Jul 15, 2013 at 11:04 AM, Anthony Floyd <anthonyfloyd@gmail.com> wrote:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

3

Hi Chris,

Thanks for your reply.

> However, some of the things we want to display are currently displayed on
> wxPython panels (gauge representations of data, for example).

Are these custom-drawn? i.e, with a DC or GC? rather than standard
controls? If so you may be able to draw them to an off-screen bitmap
and go from there. Though I think wx still requires X to be
initialized to use DCs and GCs -- but maybe port then to Cairo or
something?

Yeah, the problem is that the widgets are combined together. So while
we could self-draw the individual widgets, we rely on wxPython for
layout and use several standard controls for labelling, and so on.

> The backend servers are headless,
> non-interactive, and are not running X11. We don't really want to display
> anything on them.

There is a "dummy" X server, I think it's called Xvfb (virtual frame
buffer). I also see a devbian package called: xserver-xorg-video-dummy

Yes, Xvfb is the option I'm running with right now. I don't think it's
going to be too much effort or overhead for the boxes involved, but
it's an extra layer of complexity I was hoping to avoid.

Do your UI in the browser, then for the desktop version, embed a
browser window in a desktop app. I call this a "Browser Interface,
Local Server" app.

I've been keeping an eye on these technologies, but I don't think
we're quite ready to deal with them yet. We embed some radically
customized, interactive, and animated matplotlib plots as well as some
interactive wxVTK windows. At some point I imagine we'll move over to
HTML5-based technologies to handle this, but we're not there yet.

Thanks,
Anthony.

···

On Mon, Jul 15, 2013 at 11:29 AM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:

On Mon, Jul 15, 2013 at 11:04 AM, Anthony Floyd <anthonyfloyd@gmail.com> wrote:

4

Yes, Xvfb is the option I'm running with right now. I don't think it's
going to be too much effort or overhead for the boxes involved, but
it's an extra layer of complexity I was hoping to avoid.

understandable -- I tried it a few years back and don't actually
recall if I even got it configured correctly...But I think that's your
best option -- the wx back-ends all require an initialized GUI layer.

Do your UI in the browser, then for the desktop version, embed a
browser window in a desktop app. I call this a "Browser Interface,
Local Server" app.

I've been keeping an eye on these technologies, but I don't think
we're quite ready to deal with them yet. We embed some radically
customized, interactive, and animated matplotlib plots

that _may_ work OK -- AT SciPy, Fernando Perez demo'd a MPL-in-the
iPython-notebook example that was pretty darn cool, and remarkably
interactive (at least as long aqs the client and server were on the
same machine...)

as well as some interactive wxVTK windows.

OK, well, you do need desktop there...at least until WebGL becomes
common and robust, and VTK support its....

Sorry not to have a better option to suggest.

-Chris

···

On Mon, Jul 15, 2013 at 12:01 PM, Anthony Floyd <anthonyfloyd@gmail.com> wrote:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

5

Just as a follow-up on this topic. In the end, we ended up using Xvfb.
We use the subprocess module and a pool of workers to generate image
captures of wx.Panels with a handful of widgets on them. Each
subprocess worker creates a new wx.App as it needs, generates the
panel, "shows" it, captures the image buffer, then destroys the app.
This is all done on a headless machine, and all the subprocesses share
the same Xvfb "screen".

We found that we needed to restart the worker threads after a certain
number of uses in order to keep a handle on both stability and memory
usage. Lazy, but given the timeframe we had, restarting the workers
was much easier than trying to rundown the eventual stability/memory
growth.

These image captures, along with some plots generated by matplotlib
(which doesn't need the graphics head) are written to an images
directory on a web server several times a second, and our portable
clients grab the web pages (and images) directly from the web server.
It's pretty processor and i/o intensive, but works quite well: we have
web-pages updating at about 1/sec that are displayed on tablets and
TVs that look almost identical to our native wxPython application.

Anthony.

···

On Mon, Jul 15, 2013 at 2:14 PM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:

On Mon, Jul 15, 2013 at 12:01 PM, Anthony Floyd <anthonyfloyd@gmail.com> wrote:

Yes, Xvfb is the option I'm running with right now. I don't think it's
going to be too much effort or overhead for the boxes involved, but
it's an extra layer of complexity I was hoping to avoid.

understandable -- I tried it a few years back and don't actually
recall if I even got it configured correctly...But I think that's your
best option -- the wx back-ends all require an initialized GUI layer.

Do your UI in the browser, then for the desktop version, embed a
browser window in a desktop app. I call this a "Browser Interface,
Local Server" app.

I've been keeping an eye on these technologies, but I don't think
we're quite ready to deal with them yet. We embed some radically
customized, interactive, and animated matplotlib plots

that _may_ work OK -- AT SciPy, Fernando Perez demo'd a MPL-in-the
iPython-notebook example that was pretty darn cool, and remarkably
interactive (at least as long aqs the client and server were on the
same machine...)

as well as some interactive wxVTK windows.

OK, well, you do need desktop there...at least until WebGL becomes
common and robust, and VTK support its....

Sorry not to have a better option to suggest.

-Chris

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.