vigra::copyImage89 does not handle copy areas in the same image so the
code checks whether the src and dst are same buffer and directs it to
scaleImage() which is very slow. The whole concept of pixel accessors
is a huge overhead in the case of direct pixel copy (vigra::copyImage
is also using pixel accessors). The idea here is to identify when
direct memory copy is applicable (when the format is an integral
number of bytes per pixel, src.size==dst.size, and
src.format==dst.format) and use direct memory block copy and not
pixel-wise copy. The result is 100x faster than the vigra
implementation. This direct copy is also handling the case when the
src and dst are same buffer by copy it from bottom to top when needed
and using memmove() instead of memcpy().
Change-Id: I8ec589463d6386db82777a916371a5ebbf9e2d50
Reviewed-on: https://gerrit.libreoffice.org/5707
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
xStorable is obtained from a XComponent,
so use the original instead of requerying
a XComponent from the XStorable.
Change-Id: Iec5ca6ddcf3eedd193ec04129ba9aa1d13af1d0e
In UI localizations where the translation for such an entry is missing
the entire entry is omitted, causing the following entries to be shifted
by an offset and picking a wrong entry. Seems that rsc does not handle
this case properly.
Change-Id: I0efe1ac5d1f704ab2ba6919c4997caaca2153401
The old MsLangId::convert...() methods did implicitly fall back to a
known locale, this behavior is explicitly needed here to select a proper
completely known locale.
Change-Id: I350989f3af679890ddb0de964c2d107420331160
The reason of the crash is that the recent file opening
feature can't get the session automatically.
Change-Id: I6890c04cfdafc81d19c6b2b2024896df040fe091
The file picker can't go back folder if we use
ID mark in the URL.
Conflicts:
ucb/source/ucp/cmis/cmis_content.cxx
Change-Id: I6985feec71dc23848ee022e0bab9e8515a21ffd2
Writer core doesn't support this, and this has been a problem for table
cells as well. There the workaround we're using for quite a while is to
do the rotation at a text portion level instead, which results in
reasonable layout for simple cases. Do the same here.
One additional complexity is that the API between oox and writerfilter
is a single UNO shape, we get this property in oox, and we have to
handle it in writerfilter, when the text frame is already attached to
some text. Kill this problem by adding a FrameInteropGrabBag for sw text
frames: it's useful anyway, and then we can pass around this property
inside the grab bag.
Change-Id: Idb5ec83b5cbdde8f29d15b2cebfad24226bb6507
