On 2012-12-14 13:32, Michael Meeks wrote:
OK; interesting - if you don't think it's suitable that's fine - I had
assumed that with the reasonably demanding SVG / HTML5 canvas
requirements of the browser that it might be a reasonable fit (at least
to investigate).
It might be. I'm just
On Fri, 2012-12-14 at 12:26 +0200, Noel Grandin wrote:
> I think what he is saying is that he's happy if you take and check it
> in, but he doesn't want to take any responsibility for maintaining such
> a thing.
:-) then someone should do that I think.
> The Mozilla thing is Azure. It'
On 2012-12-14 11:52, Michael Meeks wrote:
Why not increase it's visibility ? last I looked it was beautiful and
helpful :-) I
I think what he is saying is that he's happy if you take and check it
in, but he doesn't want to take any responsibility for maintaining such
a thing.
AFAIR there ar
Hi Kohei,
On Thu, 2012-12-13 at 20:21 -0500, Kohei Yoshida wrote:
> Since proper profiling of a drawing framework takes at least a few days
> (running various benchmarks under various scenarios, and interpreting &
> writing about the results)
If you experience slow performance with a real
On 12/13/2012 04:45 AM, Michael Meeks wrote:
On Thu, 2012-12-13 at 08:51 +0200, Noel Grandin wrote:
IIRC, Cairo also runs on win32, so why not using it instead of gdi+ ?
We actually shipped a version using the cairo canvas by mistake at some
stage - that caused serious grief because o
On Thu, 2012-12-13 at 08:51 +0200, Noel Grandin wrote:
> >> IIRC, Cairo also runs on win32, so why not using it instead of gdi+ ?
We actually shipped a version using the cairo canvas by mistake at some
stage - that caused serious grief because of a (IIRC now fixed) font
rendering nasty.
On 2012-12-13 01:02, Kohei Yoshida wrote:
On 12/12/2012 05:07 PM, Enrico Weigelt wrote:
On Windows, we use gdiplus, which is notoriously slow. Optionally
using WPF there might speed things up a bit, haven't looked any
closer yet, though.
IIRC, Cairo also runs on win32, so why not using it i
On 12/12/2012 05:07 PM, Enrico Weigelt wrote:
On Windows, we use gdiplus, which is notoriously slow. Optionally
using WPF there might speed things up a bit, haven't looked any
closer yet, though.
IIRC, Cairo also runs on win32, so why not using it instead of gdi+ ?
How is cairo's performanc
> On Windows, we use gdiplus, which is notoriously slow. Optionally
> using WPF there might speed things up a bit, haven't looked any
> closer yet, though.
IIRC, Cairo also runs on win32, so why not using it instead of gdi+ ?
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC -
Kohei Yoshida wrote:
> Thanks for the info. So, I'm guess this fallback happens inside
> cairo library? IOW there isn't much we can do about it on the
> LibreOffice side?
>
The fallbacks happen in the xserver.
> My main concern was that, and the reason why I asked it was that
> when the anti-al
Hi Kohei,
On Wed, 2012-12-12 at 14:46 -0500, Kohei Yoshida wrote:
> My main concern was that, and the reason why I asked it was that when
> the anti-aliasing is enabled, the scrolling inside some quite complex
> Draw document becomes very very slow, and wondered if there was anything
> we could
On 12/12/2012 12:53 PM, Thorsten Behrens wrote:
Kohei Yoshida wrote:
I'm just wondering, whether our anti-aliasing is done strictly at software
level, or via hardware, and if former, what it would take to do it via
hardware so that we can take advantage of GPU to speed it up if it's there.
On
What I know about Nvidia Gpu's, with CUDA all it is is a C library
extension, so if it is not hardware based I dont think it would be a hard
thing to offload to the GPU. I am not sure though what AMD does with their
APU's
On Wed, Dec 12, 2012 at 4:54 PM, Kohei Yoshida wrote:
> Hi there,
>
> I'm j
Kohei Yoshida wrote:
> I'm just wondering, whether our anti-aliasing is done strictly at software
> level, or via hardware, and if former, what it would take to do it via
> hardware so that we can take advantage of GPU to speed it up if it's there.
>
On Linux, we use cairo, and XRender directly in
14 matches
Mail list logo
