summaryrefslogtreecommitdiff
path: root/vcl/inc/salgdiimpl.hxx
AgeCommit message (Collapse)Author
2024-11-21use default implementation for drawEPSNoel Grandin
so only the one that implements it needs to override it Change-Id: I19e79c5746dbbebbf5914922587016fd03a902d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176848 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-11-20use default implementation for hasFastDrawTransformedBitmapNoel Grandin
so only the one that implements it needs to override it Change-Id: I1acffb4796d95d75edc4507f533d9b1f8987972b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176790 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-11-19Simplify SalGraphicsImpl::InitNoel Grandin
it is only used for one thing, so rename it, and use a default implementation to avoid having empty implementations everywhere Change-Id: Ib650bb520ccbfcc27537b754db4d3de4ad10e638 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176733 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-11-18SalGraphics does not need virtual freeResources()Noel Grandin
it is only called to do one thing, in X11SalGraphics, so make it private to that class, and rename it to better fit its purpose. Change-Id: I16ea2f86f8b596351354faa80bb2bab4d2ac6e7c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176729 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-07-31all drawPolyPolygon variants return true nowCaolán McNamara
since: commit 4998de76ed1da4039e30718941d50d6f1dfe4f82 Date: Sun Jul 30 07:40:48 2023 +0000 tdf#156230: Drop freshly unused GenPspGfxBackend Change-Id: I7fc2a068f807777ed392c5d58772d130bf7f51c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155076 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-01-12remove newly unused X11SalGraphicsImplCaolán McNamara
Change-Id: I91d5c75f38a6798e6c4a3ce10d21fede558d27db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145337 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-21No need for bool return value hereNoel Grandin
all of the implementations of this method return true. Change-Id: I6dc02499af1809110edd482a48d9f6d5d42ead19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144620 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-11don't duplicate SalGraphics docs in SalGraphicsImplLuboš Luňák
It's incomplete anyway, and it's annoying to do it twice. Simply refer to SalGraphics. Change-Id: I6a28709e2e68ba565176ea3ddf67bd17ecf3d1e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126505 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-12-10Revert "Re-Enable DrawTransformBitmapExDirect for render backends"Armin Le Grand
This reverts commit 7e5af164b7d293dd410710bed411e1ca64bbecf7. Reason for revert: Not the best/effective way to clear out the stuff remaining to be done, would need additional stuff Change-Id: Ia6ab90384da29a5e34eff0ab8881bad2ab49c58c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126601 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-12-07Re-Enable DrawTransformBitmapExDirect for render backendsArmin Le Grand (Allotropia)
Unfortunately the add/usage of HasFastDrawTransformedBitmap did disable the system-dependent implementations/fast-path for DrawTransformBitmapExDirect and it's implemenations, except for Skia. This means that the current backends for Windows/Mac/Cairo/headless/Qt5 have to do expensive pixel operations when a Bitmap is 'really' transformed (rotate/shear) since some time. The nine implementations using ::hasFastDrawTransformedBitmap (grep for it) all return false, except the Skia one. Since HasFastDrawTransformedBitmap() uses that and itself is used in the very central mehod OutputDevice::DrawTransformedBitmapEx(...) to decide if that fast-path shall/can be used at all, it was *no longer used* - except for Skia - what makes Skia definitely performing better with transformed Bitmaps, or the other way around - the others worse. HasFastDrawTransformedBitmap() is used in only two places, the second is in the canvas helper to decide if to try to use that fast-path for presentation rendering. A method at OutputDevice to see if that fast-path is implemented is therefore currently needed, but for the canvas helper only. Since this will/should be converted to primitive usage (hopefully) anyways, nine impementations calling these virtual functions often and the danger to produce a mismatch/ error beween implementations of hasFastDrawTransformedBitmap and drawTransformedBitmap (as happened here, but can also happen when someone adds or removes an implementation) I looked for a way to solve that differenly and more safe. Since SalGraphics::DrawTransformedBitmap anyways returns a bool to signal it's success I take this as base to implement a buffered test directly at SalGraphics, also directly set a local flag to detect that functionality if DrawTransformedBitmap is used anyways before the test is/would be needed. Combined wih that small test to check only if this was not yet used and thus tested by DrawTransformedBitmap anyways I can offer a reliable non-virtual method at OutputDevice called ImplementsFastDrawTransformedBitmap() that will be used at the single necessary location - in the canvas helper. Since that small test direcly uses one of the nine implementations of hasFastDrawTransformedBitmap it is fundamenally more reliable and probably the copy bitmap/writeBack never really used (I tested that it works) due to an earlier use of DrawTransformedBitmap did the check potentially already. I also took a look at the cairo version (since I had this one running here) and ensured that the buffering of the system-dependent form of the Bitmap as cairo surface still works. Regarding the newly introduced fAlpha parameter I want to add some remarks: - It should be called fOpacity to make clear that it describes opacity, defining that if 1.0 == fAlpha means *no* transparency. That word is used in other graphic systems and makes more clear what function it has. It is the opposite of transparency, but works the same. - Currently all implementations of ::drawTransformedBitmap - except Skia where it was implemented - do not use it, but return false. It will in most cases not be too complicated to add/implement it, e.g. for cairo anyways a transparency surface will/is created, fAlpha can just be merged in, and the criteria for buffering that may be extended to remember for which value (if at all) of fAlpha that was prepared. I strongly recommend implementing these for our main graphic backends. - The primitive renderer uses another more general way to add an extra alpha channel to paint when needed - it draws the content (any content) that needs to be transparent to a buffer and then that buffer using the intended transparency. This is discussable since may be more expensive, but more general and keeps the interface less complex. We can see here that adding that complexity to the existing interface at OutputDevice makes the implementations more complex what might be the reason his was only implemented for one of nine backends. When adding something like this and extending the complexity I would prefer that at the same time it gets also *implemented* in all or most or at least most used cases. I want to make clear that from my POV in those cases choosing possible runtime speed over complexity is not always preferable. Change-Id: I5bab59f59fca878a7b11a20094e49e8b50196063 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126480 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-04-07vcl: move graphic handling into Qt5GraphicsBackendTomaž Vajngerl
This is an effort to make SalGraphicsImpl mandatory for all backends. This introduces Qt5GraphicsBackend: a subclass of SalGraphicsImpl, which now handles graphic rendering. Change-Id: I42aece59d0c692ca1dd33e30f31c5bcceab02008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113734 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-02-24actually prefer DrawTransformedBitmap() if it's known to be fastLuboš Luňák
This partially reverts the logic of change 9d89d98d3349502b56d, which always made DrawTransformedBitmap() get changed to DrawBitmapEx if only translation+scaling was involved. But since that one may call BitmapEx::Mirror() that'll do pixel-shuffling, trust the DrawTransformedBitmap() implementation to do the right and efficient thing if it says so. Change-Id: If25b3d189ddd46b235e122e5e8d6f8079ec09f7f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111248 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-24add additional 0-1 alpha argument to DrawTransformedBitmap()Luboš Luňák
This allows the VCL backends the apply the extra alpha transformation as it sees fit, rather than it being done manually elsewhere (and even if the backend doesn't implement it, at least do it in one place in the function). With the document from tdf#136223, going from slide 2 to slide 3, this easily saves 10-30% of CPU cycles. As an additional bonus, using AlphaMask::BlendWith() rather than AlphaMask::Replace() makes edges of shapes noticeably more smooth. Change-Id: I036dc9b887d6def0c7cdad3982becabdc7cd5206 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111247 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-24simply use drawTransformedBitmap()Luboš Luňák
At least with Skia this is faster than GraphicObject trying to handle it manually, even in raster mode. Change-Id: If77d108751f5621878d4ea87a996c2ea0253d111 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111246 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-08remove more no longer needed OpenGL-related codeLuboš Luňák
Change-Id: If7f47cf6dad860e4f8eab68931b72a38a7eda136 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107362 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-11-14remove SalPointNoel Grandin
<caolan> that "SalPoint" doesn't really seem to to have a purpose except to highlight that "Point" is assumed to use LONG under windows and can be passed unchanged to those windows drawing apis <caolan> so I guess remove SalPoint entirely, use Point instead, and convert to "POINT" under windows ? Change-Id: Ic15a7f4516e2075a228fa65cac4e8494d5b3abaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105634 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-19use tools::Long in vclNoel
Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-25draw linear and radial gradients directly with SkiaLuboš Luňák
Change-Id: I592fd5d823d70c6ca01e90e96a30fb6925f63545 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103282 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-05-05fix line width in DrawPolyLine() with matrix (tdf#132498)Luboš Luňák
For backends that do the object-to-device coordinates transformation directly, it's necessary to also convert the size of line width. But simply multiplying it with the matrix can also rotate the line width "vector", making it e.g. negative. So don't use just the X coordinate, use vector length for the transformation, which is ok. In fact it doesn't even make sense to treat width as a vector, because a width simply is not a vector (and for this reason it's also not actually used). Change-Id: I1241c9cb29155df105170d568a879ebc32b11a5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93203 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins
2020-02-07tdf#130478 Enhance Dashed line drawing on all systemsArmin Le Grand (Collabora)
For more info and explanation including state of process information and discussion(s) see task please. Adding corrections for gerrit build Change-Id: Ie10fb8093a86459dee80db5ab4355b47e46c1f8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88130 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2019-11-27extend vcl backendtest to more backendsLuboš Luňák
At least the KF5/Qt5 VCL plugins passes fine. Change-Id: I033ddf6ae9cc663729ca459cdc514dc0fa51ddc2
2019-11-27reimplement supportsOperation() for Skia and OpenGLLuboš Luňák
The shared X11 implementation depends on XRender, which doesn't make any sense. Change-Id: I82f36e0835a993a8b226af211d8635336960d7ec
2019-11-27Add getting of render backend name + impl. for skiaTomaž Vajngerl
Change-Id: Id4e32425579c2a3ebdc33e234f55a7324dbb39d4
2019-06-13tdf#42949 Fix IWYU warnings in vcl/inc/*Gabor Kelemen
Platform-specific subdirs are left alone: android, ios, osx, quartz, win Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Icbb906b7fbc960240c73c56d3dae2a78b06a0f53 Reviewed-on: https://gerrit.libreoffice.org/73754 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-02-26sal_uLong->sal_uInt32 in drawEPSNoel Grandin
Change-Id: I58beedfee1a55df971e778ba2aa3b6989ba53663 Reviewed-on: https://gerrit.libreoffice.org/68341 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-12-05tdf#121719: Revert fix for tdf#96971Xisco Fauli
it's still used on Mac. Revert it until XOL is removed This reverts 258301879bcd20397c38bbd522dea2c923bd9fc2 Change-Id: I06548a590f370618ad640724a1b9c59a3faceec2 Reviewed-on: https://gerrit.libreoffice.org/64582 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-09-13Support buffering SystemDependent GraphicData (II)Armin Le Grand
In this step I have changed all calls that use a B2DPolyPolygon and do filled graphics, added support for providing needed transformation which will -if supported- be used. Added buffering of SystemDependentData at B2DPolyPolygon for that purpose, see comments describing the current possibilities in the Gdiplus implementation. Moved lifetime creation/cleanup of SystemDependentDataManager to ImplSVData due to cleanup problems in the clang build Tried to use a std::unique_ptr to hold the instance of a SystemDependentDataBuffer at ImplSVData and cleanup inside DeInitVCL() right before ::ImplDeInitScheduler. This works in principle, but scheduler shutdown triggers ProcessEventsToIdle which leads to repaints and re-creates the buffer. Will now do exactly as was done with GdiPlusBuffer before, a simple local static incarnation and a call to SetStatic() in constructor Splitted SystemDependentDataBuffer and Timer due to different LifeTimes. Timer needs to be destructed earlier than SystemDependentDataBuffer, before Scheduler::ImplDeInitScheduler() is called from DeInitVCL() Change-Id: I2134e4346a183a4cee1be3428c51541cc8867c11 Reviewed-on: https://gerrit.libreoffice.org/60102 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2018-08-30Support buffering SystemDependent GraphicDataArmin Le Grand
This is a first step to allow buffering of system dependent data, especially (but not only) for the system-dependent implementations of graphic output. For example, for B2DPolygon and Win output, it allows buffering the Gdiplus::GraphicsPath instead of re- creating it all the time. To support that, the change includes forwarding the current transformation to the renderers in SalGraphics. The current state in VCL is to transform all and everything to device coordinates at every single paint. I have currently started to do this for ::drawPolyLine implementations. The fallbacks for all systems will at the start of that method just transform the data to device coordinates, so all works as before. This may also be done for FilledPolygon paint in a later step, but most urgent is FatLine painting. An arrangement of shared_ptr/weak_ptr is used so that either the instance buffering (in the example B2DPolygon) or the instance managing it can delete it. The instance managing it currently uses a 1s Timer and a cycle-lifetime management, but that can be extended in the future to e.g. include size hints, too. The mechanism it designed to support multiple Data per buffering element, e.g. for B2DPolygon at the same time system-dependent instances of Gdiplus and Cairo can be buffered, but also PDF-data. This is achieved semi-automatic by using typeid(class).hash_code() as key for organization. The mechanism will be used for now at B2DPolygon, but is not limited to. There is already a similar but less general buffer (see GdiPlusBuffer) that can and will be converted to use this new mechanism. Added vcl/headless Cairo renderer to support given ObjectToDevice transformation (not to transform given B2DPolygon) Added support for CairoPath buffered at B2DPolygon, seems to work well. Need to do more tests Moved usage to templates suggested by Noel Grandin (Noel Grandin <noelgrandin@gmail.com>), thanks for these suggestions. Adapted Win usage to that, too. Converted Win-specific GdiPlus BitmapBuffer to new mechanism, works well. Checked, the manager holds now a mix of bitmap and path data under Win Added a cleanup mechanism to flush all buffered data at DeInitVCL() using flushAll() at SystemDependentDataBuffer Adapted Linux-versions of ::drawPolyLine to support PixelSnapHairline, for now in a simplified version that still allows buffering. This will also be used (and use buffering) for the Cairo-fallback in X11SalGraphics Change-Id: I88d7e438a20b96ddab7707050893bdd590c098c7 Reviewed-on: https://gerrit.libreoffice.org/59555 Tested-by: Armin Le Grand <Armin.Le.Grand@cib.de> Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
2018-06-14return SalBitmap using std::shared_ptrNoel Grandin
since we hold it like that in Bitmap anyway Change-Id: I6264dfaaae6210cb008df5db8a421fc80c508f5b Reviewed-on: https://gerrit.libreoffice.org/55458 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-03-26replace SalColor with ColorNoel Grandin
Change-Id: I615640a378a61cf6e44e84a647ce06bdd8a52807 Reviewed-on: https://gerrit.libreoffice.org/51239 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-30Constify some VCL interface functionsJan-Marek Glogowski
This drops the bPaintEnd optimization for vertical and horizontal lines on Windows, where Polyline and LineTo exclude painting the last pixel of the line. Instead we just always set the last pixel. It also merges the various "SetPixel" call sites into a common drawPixelImpl function. Change-Id: I01cc3c01c908ba74f7978fa90eaaf8d88f923ae3 Reviewed-on: https://gerrit.libreoffice.org/43939 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-09-18Acknowledge that WinSalGraphicsImpl::drawPolyLine modifies pPtAryStephan Bergmann
Change-Id: Idde44857f8ace883cc759321c71e2ca7a4359334 Reviewed-on: https://gerrit.libreoffice.org/42406 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2016-12-07convert PolyFlags to scoped enumNoel Grandin
and remove the XPolyFlags enum, which has the same values and was being converted to PolyFlags anyhow Change-Id: Iaead84933c79a7603698a4e50257dd944df89c41 Reviewed-on: https://gerrit.libreoffice.org/31627 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-06-09tdf#96971 SetXORMode - remove un-needed parametermelikeyurtoglu
Change-Id: I901e5de3e4e25f0cae5c71d6e83fd94459fe7b7e Signed-off-by: melikeyurtoglu <aysemelikeyurtoglu@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/21951 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-by: jan iversen <jani@documentfoundation.org>
2016-05-12simplify SalGraphics::copyArea flags argumentNoel Grandin
Change-Id: Iaaef4d90d7fe817a32cd51652d41c2e49c8909a4 Reviewed-on: https://gerrit.libreoffice.org/24832 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2016-04-26tdf#48066 render stroke-miterlimit correctly in SVG importRegina Henschel
The property stroke-miterlimit is transported to the renderers via a new member mfMiterMinimumAngle in class LineAttribute Several drawPolyLine methods are adapted. This patch does not include changes in MetaAction. Presentation mode, printing, and PDF-export is still wrong. Corrected LineJoinMiter to LineJoinBevel in canvas, that s closer to NONE. Removed DrawPolyLine method without MiterMinimumAngle and adapted calls accordingly. Change-Id: I6bcd24add5d85c4d9a39e3788e0682091c5fc9c4 Reviewed-on: https://gerrit.libreoffice.org/23946 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de> Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2016-01-08vcl: this function is already documented in the base classChris Sherlock
Change-Id: I6efa86e797012b214257e745f7c7bbab0ac38461
2016-01-08vcl: this function is already documented in the base classChris Sherlock
Change-Id: I0d3b8c9026a423f95a9a0acbcd89afbc23aaff82
2015-12-24loplugin:unnecessaryvirtualNoel Grandin
and unwind some apparently now unused VCL OpenGL and GlyphCachePeer stuff. Change-Id: Ic85302d4e1ad4056dabc49c97a608891052e3167 Reviewed-on: https://gerrit.libreoffice.org/20920 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-12-15Get rid of :: prefix for basegfx in include/vcl and vclTor Lillqvist
We already used it without the :: prefix, in many cases in the same files even. It is nice to have some consistency. I was not bored enough to do it everywhere. Change-Id: Ic8ac5bd9b4b2c02c41e5ea937a3d9477824f21cf
2015-11-18com::sun::star->css in vcl/Noel Grandin
Change-Id: Ifad76177673cf93746ba221838be80ff76fed228 Reviewed-on: https://gerrit.libreoffice.org/20032 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2015-11-10loplugin:nullptr (automatic rewrite)Stephan Bergmann
Change-Id: I05e89f9896170d4df3d1377549ea074f06b884a0
2015-09-16GL paint-flushing guard re-work.Michael Meeks
Unfortunately, since we can have 2x SalGraphics' on a OutputDevice, and one of these can be a printer - things got very confused around which context to glFlush. This de-tangles the various reference-counts. Change-Id: I1062be0b02a91fc9009deaa3ec29c5dbb227df20 Reviewed-on: https://gerrit.libreoffice.org/18604 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Michael Meeks <michael.meeks@collabora.com>
2015-09-01tdf#93839 - Encourage vdevs to pick up new GL Contexts when they go invalid.Michael Meeks
Change-Id: I21726d0dd052fdc87e8dd36ff7122518325f6313
2015-07-10loplugin:unusedmethods vcl(part2)Noel Grandin
Change-Id: I12356b3fdce68282a30cae2b270b02e46558860a Reviewed-on: https://gerrit.libreoffice.org/16847 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2015-03-05this drawAlphaBitmap variant is unusedCaolán McNamara
Change-Id: Id2f9073969babe7ad5984f87949ed870f9d5a8f7
2014-11-22vcl: Always use the same OpenGL context when drawing in a windowLouis-Francis Ratté-Boulianne
Change-Id: Ief0e947149c133aaa8e81973e088c4df6432bfdc
2014-11-22vcl: Add support for backend-dependent blending of bitmaps (mask and alpha)Louis-Francis Ratté-Boulianne
Change-Id: Iba64eb42965c86ca5655b9a105ef3f397e033ecf
2014-11-13vcl: Use single-buffer rendering and only flush when necessaryLouis-Francis Ratté-Boulianne
Change-Id: I832dd6f3647fbb423975fa928a5ec32447225e85
2014-11-11vcl: Fix text rendering with OpenGLLouis-Francis Ratté-Boulianne
Change-Id: I7784fa81cb6f9a3d6437b2b628c37e7895c84733
generated by cgit (git 2.34.1) at 2025-01-05 09:42:31 +0000