Fix regressions introduced with
6a043e9c0a "Use the new type-checking
Reference constructor to reduce code noise"
Change-Id: I85662856f21c810a7db497fe3b0e116f075b1687
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
The intention was to have a container where it's fast to look elements
up, and list is a linked list, so it doesn't fit.
Change-Id: I3196c8dee96ecd4a6f464b74fd5141b27f1773b8
Building:
- The new tarball has reasonable build system so
build libgltf as external package instead of compiling
source files directly.
- Freetype dependancy is removed
Improvements comes with the new libgltf
- Can rotate the models too (orbit mode)
- Two camera handling mode: walkthrough and orbit
(press M to change).
- gltf_animation_set_time() works
- FPS can be displayed without freetype (press F)
Additional notes:
- There were some bugs/regressions which are fixed
during the integration (see patches).
- License files are uddated now.
- libgltf building is enabled only on those platforms
on which gltf support actually works (windows and linux)
Change-Id: Ia6c9c4da53a9b4fedba0d73aa5791489f8ad424b
Reviewed-on: https://gerrit.libreoffice.org/9895
Reviewed-by: Zolnai Tamás <zolnaitamas2000@gmail.com>
Tested-by: Zolnai Tamás <zolnaitamas2000@gmail.com>
This commit also does the conversion when reading the data from a data source
using the mail merge wizard.
Change-Id: Ia14417507b6ddce955fec26142a42ce51f77de4e
Apparently some time before inital CVS import a global
search-and-replace went horribly wrong and added spurious namespace
prefixes everywhere.
Change-Id: I4009bc3ab4b1d4c80412f75ad0e4628a382f99f0
Otherwise lock files etc. aren't cleaned up, which isn't particularly
nice should when then opening the file in normal LibreOffice.
Change-Id: I822b6fb582473674371a4c1d403d5a05adb7ea6b
Otherwise we get segfaults in cppu::idefaultConstructElements when exiting,
in addition to complaints of:
ignoring GError "Operation not supported" for <***RECURSION DETECTED***/log.txt>
Change-Id: If2f56873f50ba957288d1e5591db967d248ee7a4
We want to have a simple interface that allows access to tiled
rendering without digging into the internals of writer
(and in the future calc/impress/draw).
Change-Id: Ia9c278a48c919333186e5361ff25bb1ab603b846
Seems to be a gtk bug which we need to work around. The assertions
don't actually seem to cause any harm (they just print a bunch of
"Gtk-CRITICAL **: IA__gtk_range_get_adjustment: assertion `GTK_IS_RANGE (range)' failed"
but probably best to avoid them.
Change-Id: I5d1bb20bd5c0569c6d023a6148123208a15b9de2
MakeVisible only scrolls the view, so parts of the tile to be rendered
might be outside the SwView's visible area, and therefore not painted.
This however makes the background window (shown for the tilederendering
app) unuseable (but that window is invisible for all practical uses
of tiled rendering, and hence probably not a problem).
Change-Id: I6c3c2846906163b362f7cff6d8c7ba308a58a7ad
The scaling is wrong, but seems to work in principle
(i.e. we get roughly 1.5x the correct size).
Conflicts:
sc/source/ui/view/gridwin4.cxx
Change-Id: I6db1986e6cb1e5f3889ec3a462d999a9eab57331
basebmp and vcl now set the alpha channel appropriately, so no need
to do so in the viewer now.
However it would perhaps make more sense to just use RGB instead
of RGBA, seeing as the alpha channel is permanently set to be opaque.
Change-Id: I86ad758c6a8bee21b265730727a76605e5850c0c
Otherwise the alpha channel for bitmaps created directly is empty,
indicating a transparent bitmap (although we don't actually handle
transparency). This complements hardcoding of the alpha channel
in basebmp. VCL bitmaps can be copied bit-for-bit directly into
a basebmp bitmap, hence it's important to make sure we fill the
alpha channel in vcl too.
Conflicts:
include/vcl/salbtype.hxx
Change-Id: Icb2fa417db6625a6ffa6bd82eb5773ff75be5a3c
Currently the alpha channel is completely ignored by basebmp.
However this results in completely "transparent" output, meaning
the client has to manually overwrite the alpha channel -- instead
we now set it automatically when writing colourdata.
Unfortunately this doesn't quite work -- it seems that drawing
a non-opaque bitmap/image on top of the existing bitmap can
erase the alpha channel information (i.e. these areas will
once again be transparent -- for example document borders seem
to have a transition effect overlayed onto them): presumably
there is some method that bypasses our RGBMaskSetter (probably
some form of direct manipulation of raw values?).
manipulation in basebmp
Change-Id: Ia4be6a748cc30191a4422121f9ec347d9198b225
