rpav / cl-cairo2 Goto Github PK

The FFI for creating a Cairo surface doesn't work from ECL (Embedded Common Lisp)

(cairo::cairo_image_surface_create (cairo::lookup-enum :argb32 cairo::table-format)
                              100 100)

=>

#<foreign :POINTER-VOID>

I cannot figure out why, as the FFI code is very straightforward:

(cffi:defcfun ("cairo_image_surface_create" cairo_image_surface_create) :pointer
  (format cairo_format_t)
  (width :int)
  (height :int))

I'm using the following monkey patch in my program:

(in-package :cairo)

(defun format-stride-for-width (format width)
  (cairo_format_stride_for_width (lookup-enum format table-format) width))

(export 'format-stride-for-width)

The reason being is that I'm painting onto a SDL2 surface.

  (let* ((surface (get-window-surface window))
	 (x (* *dimension* *scale*))
	 (y (* 2 x))
	 (line-height x))
    (setf cairo:*context*
	  (cairo:create-context
	   (cairo:create-image-surface-for-data
	    (surface-pixels surface)
	    :argb32
	    (surface-width surface)
	    (surface-height surface)
	    (cairo:format-stride-for-width :argb32 (surface-width surface)))))
   …

The Cairo docs tell me that I need to calculate stride using cairo_format_stride_for_width, which is why I've added it. I think it would make a good addition to surface.lisp and I'd be happy to send a pull request.

Loading cl-cairo2-win32 (after loading cl-cairo2) on SBCL gives me the following:

debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR in thread              
#<THREAD "main thread" RUNNING {23F05AF1}>:                               
  Error while trying to load definition for system cl-cairo2-win32 from   
  pathname                                                                
  C:/Users/mts/quicklisp/local-projects/cl-cairo2/cl-cairo2-win32.asd:
     USE-PACKAGE #<PACKAGE "ASDF"> causes name-conflicts in               
     #<PACKAGE "CL-CAIRO2-WIN32-ASD"> between the following symbols:      
       ASDF:VERSION, CL-CAIRO2:VERSION                                    
See also:                                                                 
  The ANSI Standard, Section 11.1.1.2.5

What is the status of this project? I would like to add cl-freetype2 compatibility and bring this up-to-date with current Cairo, but I have not seen updates in quite some time.

The licensing is also a bit unclear; some systems are marked LLGPL, and others merely GPL. Is it possible for this entire project to be LLGPL?

thanks,

I am still having trouble using this library - as well as related cl-xcb-xlib (and -demos). I think I am not understanding the intended use case.

The problem is that the libraries seem to require explicit runtime loading - the asdf dependencies don't seem to be enough. Is there some kind of swig or cffi requirement? Also the sequence of loading seems to be important - cl-xcb-xlib must be loaded first?

I may be misunderstanding something, but after (ql:quickload :cl-cairo2-xlib), compiling xlib-freetype-example.lisp produces errors with (with-ft-scaled-face-locked...) macro missing (and therefore, face not being bound).

Some digging around points to the file freetype.lisp not being referenced in cl-cairo2-xlib.asd

The problem went away after I added (:file "../freetype") to the asd.

Is my usage incorrect, or is it an oversight?

Thank you.

The defpackage form in cl-cairo2 looks something like this:

(defpackage cl-cairo2
  (:nicknames :cairo)
  ; ... a bunch of stuff ...
  (:nicknames :cairo))

The duplication of the :cairo nickname causes an error on LispWorks.

Using SBCL on Windows 8.1 64-bit with a 32-bit libcairo-2.dll installed from latest gtk+3 I cannot quickload cl-cairo2 with the following error in slime

Unable to load foreign library (LIBCAIRO).
  Error opening shared object "libcairo-2.dll":
 The specified module could not be found.
   [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR]

I have installed libcairo-2.dll in C:\windows\SysWOW64 to receive the error message in slime.

I have also tried to install the experimental 64-bit version of libcairo-2.dll downloaded from cairographics.org in C:\windows\system32 with the same error message in slime.

When I try to do all of this directly in SBCL console I get the same error message.

When I put the 32-bit libcairo-2.dll in C:\windows\system32 (which is the place for 64-bit dlls) I get a new error msg

Unable to load foreign library (LIBCAIRO).
  Error opening shared object "libcairo-2.dll":
 %1 is not a valid Win32 application.
   [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR]

When I add C:\gtk\bin which contains said 32-bit dll to my system path I get this new error message again (This should work as I believe this is the correct way to install dlls and c programs do in fact find and use the dll this way).

I can compile cairo code in c using mingw gcc and run it using the 32-bit libcairo-2.dll. If i remove the 32-bit dll the program complains there is no libcairo-2.dll until I put it back in the system path (e.i C:\gtk\bin). cairo works on the system just not cl-cairo2.

I realize it might be a problem with cffi.

The image-surface-get-data function is returning the error "unknown format" for :argb32, :rgb24, and :a8 formats. A REPL session sample follows:

CAIRO> (defvar img-surface (create-image-surface :argb32 64 64))
IMG-SURFACE
CAIRO> (image-surface-get-format img-surface)
:ARGB32
CAIRO> (image-surface-get-data img-surface)

unknown format: ARGB32
[Condition of type SIMPLE-ERROR]

Restarts:
0: [RETRY] Retry SLIME REPL evaluation request.
1: [*ABORT] Return to SLIME's top level.
2: [ABORT] Exit debugger, returning to top level.

Backtrace:
0: (GET-BYTES-PER-PIXEL :ARGB32)
1: (IMAGE-SURFACE-GET-DATA #<SURFACE {10032470C1}> :POINTER-ONLY NIL)
2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (IMAGE-SURFACE-GET-DATA IMG-SURFACE) #)

It appears the culprit is that the case in get-bytes-per-pixels uses the following symbols: format-argb32, format-rgb24, and format-a8, which do not appear anywhere else in the code. Replacing these symbols with the normal :argb32, :rgb24, :a8 symbols fixes the problem. I will submit a pull request.

I didn't want to fork just for this patch, and wanted to test github issue system anyway, so patch follows:

From b83738c81a430faad72e3e4a4a8068f42a7475c5 Mon Sep 17 00:00:00 2001
From: Ramarren <[email protected]>
Date: Wed, 20 May 2009 09:19:38 +0200
Subject: [PATCH] Fix order of arguments for xlib-image-context following tpapp@9b0a4c46b78528a45fafd543a2dddc032e709ce6

---
 context.lisp            |    6 +++---
 xlib-image-context.lisp |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/context.lisp b/context.lisp
index fb919c3..c0f0e19 100644
--- a/context.lisp
+++ b/context.lisp
@@ -216,15 +216,15 @@ will be nil, as cairo can't provide that in general."

 (defmethod set-source-color (context (color rgb))
   (with-slots (red green blue) color
-    (set-source-rgb red green blue context)))
+    (set-source-rgb context red green blue)))

 (defmethod set-source-color (context (color rgba))
   (with-slots (red green blue alpha) color
-    (set-source-rgba red green blue alpha context)))
+    (set-source-rgba context red green blue alpha)))

 (defmethod set-source-color (context (color hsv))
   (with-slots (red green blue) (hsv->rgb color)
-    (set-source-rgb red green blue context)))
+    (set-source-rgb context red green blue)))


 ;;;; 
diff --git a/xlib-image-context.lisp b/xlib-image-context.lisp
index a3df1f9..3ee12c3 100644
--- a/xlib-image-context.lisp
+++ b/xlib-image-context.lisp
@@ -201,7 +201,7 @@ background-color is not nil, the window will be painted with it."
           (format nil "thread for display ~a" display-name))))))
       ;; paint it if we are given a background color
       (when background-color
-   (set-source-color background-color xlib-image-context)
+   (set-source-color xlib-image-context background-color)
    (paint xlib-image-context)
    (sync xlib-image-context))
       ;; return context
-- 
1.6.3.1

Edit: I have learnt that pasting patches into issues is not a good idea.

I'm learning cairo, so it's very possible I'm making a mistake here, so thank you ahead of time for your patience!

From what I know, Cairo exposes functions cairo_ft_scaled_font_lock_face and cairo_ft_scaled_font_unlock_face to make sure Freetype functions are not called simultaneously. cl-cairo2 wraps these two functions in the macro with-ft-scaled-face-locked. However, the two foreign functions that with-ft-scaled-face-locked uses are only available if I load either the system cl-cairo2-xcb or cl-cairo2-xlib.

I want to use Freetype fonts to write to a memory region attached to a Wayland wl_buffer. I'm under the impression that xcb and xlib are competitor libraries implementing the client-side of the X protocol, which I don't need for this use case. Do these libraries provide something beyond that, which Freetype font locking needs to work, or is this an artificial restriction?

I get this when building today:

There is no class named CL-CAIRO2::RGBA

I'm not sure what's causing it. I'm using SBCL on Linux/amd64.

image-surface-get-data only returns 3/4 of the data for RGB24 format images.

To reproduce:

1. Load or create an RGB24 image as an image surface. (I loaded a PNG with image-surface-create-from-png, but the problem is more general.)
2. Call image-surface-get-data.

I expect to get all of the data (width * height * 32 bits per pixel), however I only get 3/4 of this. The problem is that get-bytes-per-pixel incorrectly returns 3 for RGB24 format images. According to the Cairo docs, RGB24 images are 32 bits per pixel (see http://www.cairographics.org/manual/cairo-Image-Surfaces.html#cairo-format-t).

I have issued a pull request with a fix.