[erlang-questions] wxWidgets

[Barry Nicholson]

I can only give you my experience with wxWidgets.

I developed a small application with wxWidgets (SLOC - 198k).   It was 
written in a much older version of wxWidgets but has been upgraded all 
the way to wxWidgets 2.8.10.   The application was developed under VC 
2005 on Windows.  It's in daily use by approximately 10,000 users with 
no reported faults on every OS from Windows 95 (don't ask) all the way 
to Windows 7, and Windows 2000 Server to Windows 2008 Server.

At no time have I had a crash that wasn't found to be my fault.

But, I learned very early on that wxWidgets is like virtually all C/C++ 
GUI APIs.   Handling multi-threading has to be handled very carefully. 
The application has 15 main threads interacting heavily on a core set of 
data.   Changes in that data can cause MVC (model/view/controller) 
updates that reflect updates into the wxWidgets GUI world.   It is very 
important that thread 'x' doesn't call any wxWidgets functions but 
instead send messages or signals of some kind to the 'single' GUI thread 
that handles all GUI updates.  Forgetting that even once can cause a 
crash an hour later due to GUI data corruption.  Experience was a great 
teacher.

My gut feeling is that your idea of putting the GUI in a separate 
process would help.  It would enforce a more single threaded view of the 
world in the GUI.  But there's a lot of data that would have to be 
transferred back and forth to the wxWidgets process.   As an example, my 
application has a wxGrid object (similar to a spreadsheet) that can have 
several thousand rows and columns with each cell being up to 1000 bytes. 
   That ends up being megabytes of data that have to be transferred back 
and forth potentially multiple times a second.  It can be done, just how 
to do it efficiently and fast.

I'm not sure that answers all your questions, Robert but it's a start.

Barry Nicholson

On 6/15/11 7:35 AM, Robert Virding wrote:
> The wx application binding of wxWidgets seems to be cause crashes on many systems, including MacOSX. After pondering on it I have a number of questions:
>
> Is it the wxWidget implementation itself which is buggy?
>               OR
> Is the use of them directly in the BEAM which causes the crashes? Either through some inherent match problem, or version mismatch, or ...?
>
> If it is the second, would implementing a completely separate wx process solve the problem? I.e. would it be possible to implement such a process which would make linking with wxWidgets "safe"?
>
> If so, wouldn't it be better to do just that? Run wxWidgets in a separate OS process and use a (non-linked in driver) port to access it? Yes, it would be slower but it would work and be more robust.
>
> If this has already been discussed and my questions answered please point me in the right direction.
>
> Robert
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions