Summary: | Strange splashRound behaviour that sometimes causes all white render on windows. | ||
---|---|---|---|
Product: | poppler | Reporter: | Dmytro Morgun <lztoad> |
Component: | splash backend | Assignee: | poppler-bugs <poppler-bugs> |
Status: | RESOLVED WORKSFORME | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | lztoad |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | Windows (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | Suggested patch |
USE_FLOAT is a rather obscure define, is it really giving you any speed improving over doubles? Anyway i don't have a windows system nor know much modern assembler either, so i'd like a confirmation from someone that either can confirm that this is needed by running windows or knowing assembler before commiting the patch. How useful is this assembler with modern compilers and hardware? On my machine: int my_round(double x) { return (int)(x + 0.5); } with gcc -O2 compiles to: addsd .LC0(%rip), %xmm0 cvttsd2si %xmm0, %eax ret USE_FLOAT looks slowest for me (not that much, though, but I really have tests). I thought that there are two options - fixed point or float and the fixed point not sounds fast, so I wanted to test float. I stuck to double in the end, so looks like it's not that needed for me personally. Inserting after line 138 (or 158 if not for __GNUC__ && __i386__) #elif USE_FLOAT return (int)roundf(x); also fixes that behavior and looks safer, imo. So just close this bug for the moment? or? Uhm, as you wish. I really only care about the chances that we won't have to patch the new poppler version and we will use double there. But well, the described behavior is there and I think it is just as described and reproducible. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 116871 [details] Suggested patch With USE_FLOAT=ON on windows the splashRound from splash/SplashMath.h always returns 0. So it renders all white pdfs. It is caused by the line __asm fld QWORD PTR x Looks like for floats it should be. __asm fld DWORD PTR x I don't know assembler, so have no idea why (and, actually, if, I haven't compiled it for LNX) it is working with GCC for double and float values with "fldl %4" and is it safe. Strange is that there is no workaround, like in the other rounding functions in the file. That is, like #elif USE_FLOAT return (int)roundf(x); So, actually maybe it is better to use this method to fix the issue and not the attached patch. Attached is the patch to change the windows assembly code.