Hi Alan > > @Phil: > > Sorry for conflating two e-mails, but "needs must" when > I cannot communicate via SourceForge. > > There are some recent regressions in wxwidgets. > > 1. I noticed while testing the above fix that there are now affine > transformation issues again for 3D plot labels for example 8 with -dev > wxwidgets. The xwin, xcairo, and qtwidgets devices do not show this > issue even when they are resized. (So I think that xwin experiment > rules out the problem is in plbuf.) > >> From my and Andrew's recent superb experiences with git bisect, we > > highly recommend that method of finding the offending commit > that caused the above issue. > > 2. There is now also a text rotation transformation issue for example > 4 page 2 and example 26 page 2 for wxwidgets which was not there > recently. You might not need git bisect for this one since I suspect > it is the fairly recent example 3 rotation fix (by the way example 3 still > looks fine) that caused the other issues.
I am guessing that both these issues result from the fix to the buffer that allowed example 3 to be plotted correctly. This was a required change to the buffer (like Andrew's you mentioned) because there were some transformation parameters that were not being included in the buffer from the di_* functions. There is clearly some moderately complex interactions between the various transformation sources, the various unit types and the resizing of the plot in the interactive drivers. I obviously haven't quite gotten to the bottom of this yet. It is not jst a case of undoing some change from a commit, because those changes were required to get example 3 correct. I think that both the text and the aspect ratio of the plots are related - in fact I have a feeling that somehow the text is being plotted in the correct position and with the correct transformation, however the lines are being plotted with an incorrect aspect. I probably need to sit down for a few hours and dig through all this again. I should get chance to do so at the weekend. >In the spirit of attempting to encourage you in that bug hunt, I have >been looking carefully at the wxwidgets fonts setting code and the >2.8.12 version of the wxwidgets documentation in light of the missing >glyphs for two of the example 23 glyphs, and many of the example 24 >glyphs. Furthermore, when going through that documentation, I noticed ><http://docs.wxwidgets.org/2.8.12/wx_samples.html#samplefont >>. >Fortunately, Debian stable packages that sample code (along with the >rest of the samples). I was able to build that font sample cleanly, >and the resulting GUI is similar in spirit to the wonderful gucharmap >GUI. For example, it lets you look at how wxwidgets renders text font >results for any text you might want to put in so I chose to do that >for the utf-8 part of examples/c/x24c.c, and each of the Peace words >were rendered beautifully and correctly (including the complex text >layout languages such as Arabic, Hebrew, and Hindi) in that GUI! So >that good result implies that getting example 24 working properly for >the wxwidgets device driver built against the (Debian stable) >wxwidgets-2.8.12 libraries should be straightforward. Okay that sounds promising, I take it from this that I can leave this in your hands for now while I deal with the aspect ratio bugs? > > Finally, another strong "would be nice" is to rewrite > drivers/README.wxwidgets > which your work has completely outdated now (so it is positively > misleading). And also please put a paragraph into README.Release > describing your recent wxwidgets work. Yes I very much agree and the user documentation will probably need a rewrite which really should be done before release. >So as you both are already aware, I have postponed the release to at >least March 4th, but it struck me tonight that I did not want to >disrupt your bug fixing by some artificial deadline. So this is in many ways up to you as the release manager. Many of the bugs we are uncovering here are long standing bugs related to the buffer, so in some ways one could say that we should not stress too much about them. However the move to using the buffer for initial rendering of wxWidgets (when run via wxPLViewer from a console app) has exposed them in a way that makes them rather obvious to any user. For people making use of this driver it wouldn't be great if suddenly we broke their code. I would imagine that there is another week or two of work to bring the wxWidgets driver/binding up to scratch. So fundamentally I see three options 1) Release quickly regardless of the wxWidgets status and just live with the fact that the driver isn't really up to scratch. 2) Wait another couple of weeks to get the driver into a state where we are happy it is of at least a similar quality to the old driver 3) Branch from master before my first push of the new wxWidgets driver and release that version. We can then merge the wxWidgets and buffer fixes back in post release and go for another release in a few months when we have had time to really get everything ironed out I'm sure there are potentially other options I haven't thought of too. However I could do with knowing what I should and shoudn't be tampering with now. For example there is an inherited state issue with the buffer that I thought was too intrusive to deal with now. I have put it on Trac as a reminder for later, but I didn't see an email about it on the list. This is the cause of the bad colours on e.g. example 19. The slow rendering of some examples can be speeded up by better memory allocation strategies, but again this requires t=some changes to plbuf.c so I was going to leave this to post release. If we are postponing then perhaps I should fix these now. Phil ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
