AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
2fe01a5b57
gtk2/gsk/Makefile.am

268 lines
7.7 KiB
Makefile
Raw Normal View History

gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
include $(top_srcdir)/Makefile.decl
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
GSK_CFLAG_DEFINES = \
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
-DG_LOG_DOMAIN=\"Gsk\" \
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
-DG_LOG_USE_STRUCTURED=1 \
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
-DGSK_COMPILATION
AM_CPPFLAGS = \
$(GSK_CFLAG_DEFINES) \
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
-I$(top_srcdir) \
-I$(top_srcdir)/gdk \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
-I$(top_builddir) \
-I$(top_builddir)/gsk \
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
$(GTK_DEBUG_FLAGS) \
$(GTK_WARN_FLAGS) \
$(GSK_DEP_CFLAGS)
BUILT_SOURCES =
CLEANFILES =
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
DISTCLEANFILES =
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
noinst_LTLIBRARIES =
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
if HAVE_VULKAN
Fix distcheck
2016-12-21 19:12:17 +00:00
gsk_private_vulkan_source_h = \
vulkan: Add GskVulkanBlendPipeline So far that's just a simple pipeline that doesn't do anything.
2016-12-17 23:57:37 +00:00
gskvulkanblendpipelineprivate.h \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanbufferprivate.h \
gsk: Add GskVulkanClip This is now tracking the clips added by the clip nodes. If any particular node can't deal with a clip, it falls back to Cairo rendering. But if it can, it will render it directly.
2016-12-23 20:36:17 +00:00
gskvulkanclipprivate.h \
vulkan: Split color and blend pipelines
2016-12-18 01:18:01 +00:00
gskvulkancolorpipelineprivate.h \
vulkan: Split out command pool This way we can pass the command pool around. And that allows us to allocate and submitcustom buffers. And that is necessary to make staging images work.
2016-12-16 05:10:24 +00:00
gskvulkancommandpoolprivate.h \
vulkan: Handle opacity nodes Well, "handle" them actually. We still draw the node's child using Cairo, but we apply the opacity manually now.
2016-12-30 05:46:34 +00:00
gskvulkaneffectpipelineprivate.h \
vulkan: Make GskVulkanRenderer work We now create a Cairo renderer, render to an image surface and upload and retnder it with Vulkan.
2016-12-06 13:42:46 +00:00
gskvulkanimageprivate.h \
vulkan: Handle opacity nodes Well, "handle" them actually. We still draw the node's child using Cairo, but we apply the opacity manually now.
2016-12-30 05:46:34 +00:00
gskvulkanlineargradientpipelineprivate.h \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanmemoryprivate.h \
gskvulkanpipelineprivate.h \
vulkan: Add infrastructure for push constants THe code includes fragment push constants for colors, but that code is so far unused.
2016-12-14 06:21:21 +00:00
gskvulkanpushconstantsprivate.h \
vulkan: Add GskVulkanRender object This is refactoring work. GskVulkanRender is supposed to be the global object for a render operation, ie GskVulkanRenderer.render() will create this object for what it does. The object will be split into stages that perform the operations necessary to create a drawing.
2016-12-07 13:50:52 +00:00
gskvulkanrenderprivate.h \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanrendererprivate.h \
vulkan: Add GskVulkanRenderPass And move the actual rendering code there. A RenderPass is a collection of operations on the same target that get executed one after another. It roughly targets VkRenderPass or rather the subpasses of a VkRenderPass. For now, only the infrastructure is there. No real stuff is happening.
2016-12-08 12:26:36 +00:00
gskvulkanrenderpassprivate.h \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanshaderprivate.h
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
gsk_private_vulkan_source_c = \
vulkan: Add GskVulkanBlendPipeline So far that's just a simple pipeline that doesn't do anything.
2016-12-17 23:57:37 +00:00
gskvulkanblendpipeline.c \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanbuffer.c \
gsk: Add GskVulkanClip This is now tracking the clips added by the clip nodes. If any particular node can't deal with a clip, it falls back to Cairo rendering. But if it can, it will render it directly.
2016-12-23 20:36:17 +00:00
gskvulkanclip.c \
vulkan: Split color and blend pipelines
2016-12-18 01:18:01 +00:00
gskvulkancolorpipeline.c \
vulkan: Split out command pool This way we can pass the command pool around. And that allows us to allocate and submitcustom buffers. And that is necessary to make staging images work.
2016-12-16 05:10:24 +00:00
gskvulkancommandpool.c \
vulkan: Handle opacity nodes Well, "handle" them actually. We still draw the node's child using Cairo, but we apply the opacity manually now.
2016-12-30 05:46:34 +00:00
gskvulkaneffectpipeline.c \
vulkan: Handle linear gradients Note: We interpolate premultiplied colors as per the CSS spec. This i different from Cairo, which interpolates unpremultiplied. So in testcases with translucent gradients, it's actually Cairo that is wrong.
2016-12-26 16:11:13 +00:00
gskvulkanlineargradientpipeline.c \
vulkan: Make GskVulkanRenderer work We now create a Cairo renderer, render to an image surface and upload and retnder it with Vulkan.
2016-12-06 13:42:46 +00:00
gskvulkanimage.c \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanmemory.c \
gskvulkanpipeline.c \
vulkan: Add infrastructure for push constants THe code includes fragment push constants for colors, but that code is so far unused.
2016-12-14 06:21:21 +00:00
gskvulkanpushconstants.c \
vulkan: Add GskVulkanRender object This is refactoring work. GskVulkanRender is supposed to be the global object for a render operation, ie GskVulkanRenderer.render() will create this object for what it does. The object will be split into stages that perform the operations necessary to create a drawing.
2016-12-07 13:50:52 +00:00
gskvulkanrender.c \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanrenderer.c \
vulkan: Add GskVulkanRenderPass And move the actual rendering code there. A RenderPass is a collection of operations on the same target that get executed one after another. It roughly targets VkRenderPass or rather the subpasses of a VkRenderPass. For now, only the infrastructure is there. No real stuff is happening.
2016-12-08 12:26:36 +00:00
gskvulkanrenderpass.c \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
gskvulkanshader.c
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
endif
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk_public_source_h = \
gskenums.h \
gskrenderer.h \
gskrendernode.h \
gsk: Add GskRoundedRect It's essentially a port of GtkRoundedBox to graphene.
2016-12-13 18:02:12 +00:00
gskroundedrect.h \
gsk: Add GskTexture
2016-11-07 16:59:38 +00:00
gsktexture.h \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsktypes.h
gsk_private_source_h = \
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
$(gsk_private_vulkan_source_h) \
gsk: Move gtk/gtkcairoblur.c to gsk/gskcairoblur.c
2016-12-18 20:45:15 +00:00
gskcairoblurprivate.h \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskcairorendererprivate.h \
gskdebugprivate.h \
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
gskgldriverprivate.h \
gsk: Add GL profiler We can use the GL_ARB_timer_query extension (available since OpenGL 3.2, and part of the OpenGL specification since version 3.3) to query the time elapsed when drawing each frame. This allows us to gather timing information on our use of the GPU.
2016-07-12 13:50:48 +00:00
gskglprofilerprivate.h \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskglrendererprivate.h \
gsk: Add ShaderBuilder GskShaderBuilder is an ancillary, private type that deals with the internals of taking GLSL shaders from resources and building them, with the additional feature of being able to compose shaders from a common preamble, as well as adding conditional defines (useful for enabling debugging code in the shaders themselves).
2016-07-03 19:04:40 +00:00
gskprivate.h \
gsk: Add profiler object The GskProfiler holds counters and timers, and will be used by the renderer implementations to acquire frame timings.
2016-08-03 15:48:49 +00:00
gskprofilerprivate.h \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskrendererprivate.h \
gskrendernodeprivate.h \
gsk: Add GskRoundedRect It's essentially a port of GtkRoundedBox to graphene.
2016-12-13 18:02:12 +00:00
gskroundedrectprivate.h \
gsk: Add GskTexture
2016-11-07 16:59:38 +00:00
gskshaderbuilderprivate.h \
gsktextureprivate.h
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
gsk_public_source_c = \
gskrenderer.c \
gskrendernode.c \
gsk: Split render node subclasses out into their own file
2016-12-11 01:59:47 +00:00
gskrendernodeimpl.c \
gsk: Add GskRoundedRect It's essentially a port of GtkRoundedBox to graphene.
2016-12-13 18:02:12 +00:00
gskroundedrect.c \
gsk: Add GskTexture
2016-11-07 16:59:38 +00:00
gsktexture.c
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk_private_source_c = \
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
$(gsk_private_vulkan_source_c) \
gsk: Move gtk/gtkcairoblur.c to gsk/gskcairoblur.c
2016-12-18 20:45:15 +00:00
gskcairoblur.c \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskcairorenderer.c \
gskdebug.c \
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
gskgldriver.c \
gsk: Add GL profiler We can use the GL_ARB_timer_query extension (available since OpenGL 3.2, and part of the OpenGL specification since version 3.3) to query the time elapsed when drawing each frame. This allows us to gather timing information on our use of the GPU.
2016-07-12 13:50:48 +00:00
gskglprofiler.c \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskglrenderer.c \
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
gskprivate.c \
gsk: Add profiler object The GskProfiler holds counters and timers, and will be used by the renderer implementations to acquire frame timings.
2016-08-03 15:48:49 +00:00
gskprofiler.c \
gsk: Add ShaderBuilder GskShaderBuilder is an ancillary, private type that deals with the internals of taking GLSL shaders from resources and building them, with the additional feature of being able to compose shaders from a common preamble, as well as adding conditional defines (useful for enabling debugging code in the shaders themselves).
2016-07-03 19:04:40 +00:00
gskshaderbuilder.c
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
gsk_built_source_h = \
gskenumtypes.h \
gskresources.h
gsk_built_source_c = \
gskenumtypes.c \
gskresources.c
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
all_sources = \
$(gsk_public_source_h) \
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
$(gsk_public_source_c) \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
$(gsk_private_source_h) \
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
$(gsk_private_source_c)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
BUILT_SOURCES += $(gsk_built_source_h) $(gsk_built_source_c) gsk.resources.xml
gskenumtypes.h: $(gsk_public_source_h) gskenumtypes.h.template
$(AM_V_GEN) $(GLIB_MKENUMS) --template $(filter %.template,$^) $(filter-out %.template,$^) > \
gskenumtypes.h.tmp && \
mv gskenumtypes.h.tmp gskenumtypes.h
gskenumtypes.c: $(gsk_public_source_h) gskenumtypes.c.template
$(AM_V_GEN) $(GLIB_MKENUMS) --template $(filter %.template,$^) $(filter-out %.template,$^) > \
gskenumtypes.c.tmp && \
mv gskenumtypes.c.tmp gskenumtypes.c
EXTRA_DIST += gskenumtypes.h.template gskenumtypes.c.template
DISTCLEANFILES += gskenumtypes.h gskenumtypes.c
resource_files = $(shell $(GLIB_COMPILE_RESOURCES) --sourcedir=$(srcdir) --generate-dependencies $(builddir)/gsk.resources.xml)
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
resources/vulkan/%.frag.spv: resources/vulkan/%.frag.glsl
@if test -z "$(GLSLC)"; then echo "Missing glslc. See https://github.com/google/shaderc"; exit 1; fi
$(AM_V_GEN) $(GLSLC) -fshader-stage=fragment -o $@.tmp $< && mv $@.tmp $@
resources/vulkan/%.vert.spv: resources/vulkan/%.vert.glsl
@if test -z "$(GLSLC)"; then echo "Missing glslc. See https://github.com/google/shaderc"; exit 1; fi
$(AM_V_GEN) $(GLSLC) -fshader-stage=vertex -o $@.tmp $< && mv $@.tmp $@
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk.resources.xml: Makefile.am
$(AM_V_GEN) echo "<?xml version='1.0' encoding='UTF-8'?>" > $@; \
echo "<gresources>" >> $@; \
echo " <gresource prefix='/org/gtk/libgsk'>" >> $@; \
for f in $(top_srcdir)/gsk/resources/glsl/*; do \
n=`basename $$f`; \
echo " <file alias='glsl/$$n'>resources/glsl/$$n</file>" >> $@; \
done; \
gsk: Loads of work on Vulkan backend We can now upload vertices. And we use this to draw a yellow background. Which is clearly superior to not drawing anything. Also, we have shaders now. If you modify them, you need glslc installed so they can be recompiled into Spir-V bytecode.
2016-12-05 01:50:06 +00:00
for f in $(top_srcdir)/gsk/resources/vulkan/*.spv; do \
n=`basename $$f`; \
echo " <file alias='vulkan/$$n'>resources/vulkan/$$n</file>" >> $@; \
done; \
for f in $(top_srcdir)/gsk/resources/vulkan/*.glsl; do \
n=`basename $$f`; \
echo " <file alias='vulkan/$$n'>resources/vulkan/$$n</file>" >> $@; \
done; \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
echo " </gresource>" >> $@; \
echo "</gresources>" >> $@
gskresources.h: gsk.resources.xml
$(AM_V_GEN) $(GLIB_COMPILE_RESOURCES) $< \
--target=$@ --sourcedir=$(srcdir) --c-name _gsk --generate-header --manual-register
gskresources.c: gsk.resources.xml $(resource_files)
$(AM_V_GEN) $(GLIB_COMPILE_RESOURCES) $< \
--target=$@ --sourcedir=$(srcdir) --c-name _gsk --generate-source --manual-register
EXTRA_DIST += $(resource_files)
CLEANFILES += gsk.resources.xml
DISTCLEANFILES += gskresources.h gskresources.c
libgsk_4_la_SOURCES = $(all_sources)
nodist_libgsk_4_la_SOURCES = $(gsk_built_source_h) $(gsk_built_source_c)
libgsk_4_la_CFLAGS = $(AM_CFLAGS) $(GDK_HIDDEN_VISIBILITY_CFLAGS)
libgsk_4_la_LIBADD = $(GSK_DEP_LIBS) $(top_builddir)/gdk/libgdk-4.la
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
noinst_LTLIBRARIES += libgsk-4.la
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gskincludedir = $(includedir)/gtk-4.0/gsk
gskinclude_HEADERS = $(gsk_public_source_h) gskenumtypes.h gsk.h
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
-include $(INTROSPECTION_MAKEFILE)
INTROSPECTION_GIRS =
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
INTROSPECTION_SCANNER_ENV = CC="$(CC)"
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
INTROSPECTION_SCANNER_ARGS = \
--add-include-path=../gdk \
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
--add-include-path=../gsk \
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
--warn-all
INTROSPECTION_COMPILER_ARGS = \
--includedir=$(srcdir) \
--includedir=. \
--includedir=../gdk
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
if HAVE_INTROSPECTION
build: Rework the GSK source lising We need to only parse the public sources during the introspection step, otherwise the introspection scanner will try to access private data types.
2016-10-18 14:47:00 +00:00
introspection_files = $(gsk_public_source_h) $(gsk_public_source_c)
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
gsk: ensure libgsk-4.la before running g-ir-scanner https://bugzilla.gnome.org/show_bug.cgi?id=775410
2016-11-30 15:06:43 +00:00
Gsk-noinst-4.0.gir: libgsk-4.la Makefile
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
Gsk_noinst_4_0_gir_SCANNERFLAGS = \
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
--add-include-path=$(top_builddir)/gdk \
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
--include-uninstalled=$(top_builddir)/gdk/Gdk-noinst-4.0.gir \
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
--c-include="gsk/gsk.h"
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
Gsk_noinst_4_0_gir_LIBS = libgsk-4.la
Gsk_noinst_4_0_gir_FILES = $(introspection_files)
Gsk_noinst_4_0_gir_CFLAGS = $(AM_CPPFLAGS) $(GDK_HIDDEN_VISIBILITY_CFLAGS)
Gsk_noinst_4_0_gir_EXPORT_PACKAGES = gsk-4.0
Gsk_noinst_4_0_gir_INCLUDES = GObject-2.0 cairo-1.0 Graphene-1.0
INTROSPECTION_GIRS += Gsk-noinst-4.0.gir
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
Make gdk.la and gsk.la a noninst helper library This merged gtk, gdk and gsk into one library, making it possible to have internal private APIs between gtk them, as well as producing more efficient code. https://bugzilla.gnome.org/show_bug.cgi?id=773100
2016-10-17 13:07:57 +00:00
noinst_DATA = $(INTROSPECTION_GIRS)
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
build: Clean the uninstalled introspection GIR files We need to remove them from the build when cleaning them. Additionally, this automatically adds them to the Git ignore file.
2016-10-31 16:30:10 +00:00
CLEANFILES += $(INTROSPECTION_GIRS)
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
endif
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
# ------------------- MSVC Build Items ----------------
MSVCPROJS = gsk-4
gsk_4_FILES = $(all_sources) $(gsk_built_source_c)
Visual Studio builds: Include Vulkan sources in GSK ...but disable them for now. Configs will be added for the projects to support Vulkan-enabled builds which will then enable the builds of these sources. Extra commands and items will be needed for the GSK resources along with ensuring GSK_RENDERER_GSK being defined for the build of GDK, GDK-Win32 and GSK so that the builds of Vulkan-enabled builds can be done properly. Filter out the Vulkan sources from the 'dist hook' rules in gsk/Makefile.am as we don't want to in turn include them twice in the projects when the 'make dist' is performed on a system with Vulkan builds enabled.
2016-12-29 17:08:07 +00:00
gsk_4_EXCLUDES = gskvulkan*.c
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
gsk_4_HEADERS_DIR = $(gskincludedir)
gsk_4_HEADERS_INST = $(gskinclude_HEADERS)
gsk_4_HEADERS_EXCLUDES = dummy
include $(top_srcdir)/build/Makefile.msvcproj
$(top_builddir)/build/win32/gsk.enum.headers: Makefile $(gsk_public_source_h)
-$(RM) $(top_builddir)/build/win32/gsk.enum.headers
for F in $(gsk_public_source_h); do \
case $$F in \
*.h) \
echo $$F' ^'>>$(top_builddir)/build/win32/gsk.enum.headers \
;; \
esac \
done
if HAVE_INTROSPECTION
# Introspection Items for MSVC
MSVC_INTROSPECT_GIRS = Gsk-4.0.gir
BASE_MSVC_GIR_CFLAGS = \
$(GSK_CFLAG_DEFINES) \
-I../.. -I../../gdk -I.../../gsk
INTROSPECTION_INTERMEDIATE_ITEMS = \
$(top_builddir)/build/win32/Gsk-4.0.gir.msvc.introspect \
$(top_builddir)/build/win32/Gsk_4_0_gir_list \
$(top_builddir)/build/win32/gsk.enum.headers
Gsk_4_0_gir_MSVC_FILES = $(introspection_files)
autotools: Update MSVC gir build script generation Now that GTK+ is built as a single DLL, and the .lib that is built is gtk-4.lib, we need to update the autotools sections in generating the NMake Makefile snippets so that we can have the correct commands and flags for building the .gir files, which will all now link to gtk-4-vsXX.dll (or so).
2016-11-03 10:00:03 +00:00
Gsk_4_0_gir_MSVC_EXPORT_PACKAGES = $(Gsk_noinst_4_0_gir_EXPORT_PACKAGES)
Gsk_4_0_gir_MSVC_INCLUDE_GIRS = $(Gsk_noinst_4_0_gir_INCLUDES)
Gsk_4_0_gir_MSVC_LIBS = gtk-4
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
Gsk_4_0_gir_MSVC_CFLAGS = $(BASE_MSVC_GIR_CFLAGS)
Gsk_4_0_gir_MSVC_SCANNERFLAGS = \
--add-include-path=. \
autotools: Update MSVC gir build script generation Now that GTK+ is built as a single DLL, and the .lib that is built is gtk-4.lib, we need to update the autotools sections in generating the NMake Makefile snippets so that we can have the correct commands and flags for building the .gir files, which will all now link to gtk-4-vsXX.dll (or so).
2016-11-03 10:00:03 +00:00
--include-uninstalled=../gdk/Gdk-4.0.gir
GSK: Add initial Visual Studio projects This adds the initial MSVC build items needed to build GSK under Visual Studio, this is part of it that is required, we need to add items to the property sheets to generate the code that is generated via glib-mkenums and glib-compile-resources. This set includes, with the autotools scripts for the complete: -GSK project files, which is integrated into the gtk+-4.sln. -The NMake snippets to build the introspection files for GSK. -The .bat files to call glib-mkenums to generate the enumeration sources.
2016-10-26 10:23:38 +00:00
include $(top_srcdir)/build/Makefile.msvc-introspection
else
INTROSPECTION_INTERMEDIATE_ITEMS =
endif
dist-hook: \
$(top_builddir)/build/win32/vs12/gsk-4.vcxproj \
$(top_builddir)/build/win32/vs12/gsk-4.vs12.headers \
$(top_builddir)/build/win32/gsk.enum.headers \
$(INTROSPECTION_INTERMEDIATE_ITEMS)
gsk: Initial commit / build environment
2014-01-14 13:01:35 +00:00
-include $(top_srcdir)/git.mk
Reference in New Issue Copy Permalink