Add a dlo-based layout callback for use with lhp.
If lhp_dl_render() is used as the Lws Html/CSS parser callback, it
produces a display_list representation of the Html as DLOs, referencing the
appropriate CSS to drive the layout as best it can.
The display list can be rasterized on to an lws_display using the display's
state object
lds->disp->blit(lds, (uint8_t *)&dl, &box);
This adds optional display list support to lws_display, using DLOs (Display
List Objects). DLOs for rectangle / rounded rectangle (with circle as the
degenerate case), PNGs, JPEG and compressed, antialiased bitmapped fonts
and text primitives are provided.
Logical DLOs are instantiated on heap and listed into an lws_display_list
owner, DLOs handle attributes like position, bounding box, colour +
opacity, and local error diffusion backing buffer.
When the display list is complete, it can be rasterized a line at a time,
with scoped error diffusion resolved, such that no allocation for the
framebuffer is required at any point. DLOs are freed as the rasterization
moves beyond their bounding box.
Adds a platform registry binding names and other metadata to lws_display
fonts / PNGs / JPEGs. Provides registration, destruction and best match
selection apis.
This adds apis that enable usage of compressed backtraces in heap
instrumentation.
A decompressor tool is also provided that emits a textual
call stack suitable for use with addr2line.
Fix build failure against Atmel ASF3 SDK that does not provide a file
API conforming to POSIX.
libwebsockets/lib/core/libwebsockets.c: In function 'lws_open':
libwebsockets/lib/core/libwebsockets.c:187:18: error: 'O_CREAT' undeclared (first use in this function)
if (((__oflag & O_CREAT) == O_CREAT)
^~~~~~~
Esp-idf has an improved but still kind of abused cmake-
based build system now.
If we see ESP_PLATFORM coming as a cmake var, we can know we
are being built from inside the esp-idf config system.
Leave the existing esp32 arrangements alone but triggered off
ESP_PLATFORM, adapt to use the cross toolchain file and
various quirks automatically.
In this way you can build lws a part of your project in a
much cleaner way.
Prepare a minimal esp32 test app for use in Sai
Adapt .sai.json to build for esp32
This provides support to build lws using the linkit 7697 public SDK
from here https://docs.labs.mediatek.com/resource/mt7687-mt7697/en/downloads
This toolchain has some challenges, its int32_t / uint32_t are long,
so assumptions about format strings for those being %u / %d / %x all
break. This fixes all the cases for the features enabled by the
default cmake settings.
The cmake config on the build system actually decides the release build optimization policy.
On Fedora, it's -O2. On Ubuntu, it's -O3.
Anything given in CMakeLists.txt is overridden by the build system policy since it goes at
the end of the compiler commandline.
When you are building cross, the build system's opinion of your cross binary optimization
level is irrelevant, and at worst destructive. Some versions of gcc contain broken optimizations
that are applied only at -O3.
This patch removes any doomed attempt to set -O in CMakeLists.txt, which has
no effect since the build system policy is still added at the end, but
removes confusion; and adds code to all the cross build files to forcibly
override release optimization level to -O2, removing the build system's
opinion of how your cross build should look.
Almost all the CMake options begin with LWS_WITH_..., but many of the
symbols passed to lws are LWS_USE_... , this causes neededless confusion,
compounded by the fact that a few CMake options also begin with
LWS_USE_.
This patch globally converts all LWS_USE_... to LWS_WITH_..., so there
is only one prefix to remember in both CMake and the code.
The affected public CMake options are
LWS_USE_BORINGSSL -> LWS_WITH_BORINGSSL
LWS_USE_CYASSL -> LWS_WITH_CYASSL
LWS_USE_WOLFSSL -> LWS_WITH_WOLFSSL
LWS_USE_MBEDTLS -> LWS_WITH_MBEDTLS
LWS_USE_BUNDLED_ZLIB -> LWS_WITH_BUNDLED_ZLIB
