Home Page Forums MAME QMC2 QMC2 SVN news

It is fast enough on Linux, a bit slower when it comes to very image-intensive PDFs... anyway, it's something that would have to be addressed in the upstream project (PDF.js).

Also, comparing QMC2's integrated PDF viewer with Firefox's one using FF 27.0.1 on Linux x86_64 I actually see no difference in performance. No surprise though: they use the same JS library.

The only realistic (and open source) alternative to PDF.js that I see is Poppler, but the reason I refrained from using it is that it has many library dependencies which should be no problem in the Linux world, but I'd need to include them all in QMC2's code because of platform independence... and that's pure overkill . However, Poppler is likely faster, mainly because it's written in C++ and can be easily integrated with Qt (which is really nice!), but still...

Another problem is that some browser features which are required by PDF.js are not (yet) supported in QtWebKit (tried Qt 4.8.5 and 5.1.1, same as support by Safari). Just open this URL in QMC2's built-in browser:

http://mozilla.github.io/pdf.js/features/

Firefox 27 is 'green' for all the required features. So that's also why I call this 'experimental' at the moment . The missing features mainly affect PDFs in East Asian languages.

Safari 7.0.2 on OS X shows all green except two features required for CJK support, so I imagine when QtWebKit catches up with WebKit proper it'll be in better shape.

Yeah, and the missing features aren't that important as far as I can tell... the main issue really is performance in case of large PDFs, and depending on the PDF structure, rendering sometimes takes 'forever'. But PDF.js is steadily progressing, so I think this will be sorted out sooner or later.

Yeah, that's my main issue with it in Firefox so far. It doesn't help that my PC is dog-slow tho...

FWIW, I just tried it with Qt 5.2.1 which uses a much newer webkit and it looks a lot better in this case.

EDIT: Yesterday I recognized that I was using the library in the wrong way... I used the source directly, but it's supposed to be "built" using node-js ('node make generic') and then use the resulting build-output in production code. So, the complete data/js/pdfjs directory has changed again . Some things even work better now.

SVN r5768 (full change-log):

• fix: main GUI / key- & joy-mapping: don't trigger disabled actions
• imp: Windows: the FileSystemModel's directory scanner thread now uses native Win32 API calls instead of Qt classes -- see also bug tracker ID #56
• imp: added a FileIconProvider wrapper class for QFileIconProvider that uses native Win32 API calls on Windows for better performance (also caches the icons internally)

SVN r5776 (full change-log):

• fix: MESS device configurator: avoid crash (seen on Windows) when the selected system changes while the available devices and slot-options are currently being determined for another system

SVN r5798 (full change-log):

• fix: initial ROM path check: corrected handling of relative ROM paths
• fix: updated the handling of character encoding in software-lists on Windows to modern MAME/MESS/UME -- see also bug tracker ID #65
• fix: corrected the working directory the emulator would use when scanning software-lists (so that a relative hash path would actually be found)
• fix: demo-mode (minor): corrected the produced command line when 'maximize' is disabled
• imp: updated template format to v0.2.7 which adds support for a new relativeTo attribute (valid only for file-type options) which - if set - will be used to generate a path relative to the current value of the referenced directory-type option when using a file-picker
• imp: replaced some icons in the classic image-set
• imp: produce a nicer command line when the emulator is launched in embedded- or demo-mode (no duplicate or redundant options)