Groups together consecutive mouse move events like done in core.step()
lua function but on the C side.
It does not introduce any meaningful speedup but it theory is more efficient and
simplifies the Lua code.
The simplification of the Lua code alone is enough to justify this change?
* Retrieve scale plugin from lite-plugins
* New implementation of scale plugin and font C API
Introduce two new C API functions, renderer.font.get_size and set_size
respectively to get the font size and to set the size to a new value.
Using these functions we don't need to know the name of the font but
we can just change their size.
Adapt the scale plugin to use the new C API function with minor adaptations
in the logic.
Use smaller step to scale fonts.
Rename font_desc_free function, previous name was misleading as only the cached
resources are freed.
* Add contextmenu plugin from takase
From https://github.com/takase1121/lite-contextmenu
Adapted to show font scaling commands and find/replace commands.
i# testing.lua
* Fix the cursor flickering with contextmenu
To avoid flickering of the cursor when using the context menu
we add a new function `core.request_cursor` that just take note
of the cursor requested.
The cursor will be actually changed only in root_view:draw() method
only when all the drawing operations are done. This means the cursor
will be changed only once per frame and only the most recent cursor
change request will take effect.
* Remove unneeded scale plugin return functions
On macos 11.2.3 with sdl 2.0.14 the keyup handler for cmd+w was not
enough. Maybe the quit event started to be triggered from the keydown
handler? In any case, flushing the quit event there too helped.
Use resolved executablePath instead of resourcePath to allow lanching
the lite-xl binary via a symlink, like typically done by Homebrew:
/usr/local/bin/lite-xl -> /Applications/lite-xl.app/Contents/MacOS/lite-xl
The resourcePath returns /usr/local in this case instead of
/Applications/lite-xl.app/Contents/Resources, which makes later
access to the resource files fail. Resolving the symlink to the
executable and then the relative path to the expected directory
Resources is a workaround for starting the application from both
the launcher directly and the command line via the symlink.
Use regular expressions instead of Lua patterns for find and replace editor commands.
Syntax files can now use regex or Lua patterns as before keeping backward compatibility for plugins.
In some cases rencache was using a FontDesc pointer that was actually freed by
Lua giving segfaults errors.
In addition, some FontDesc object were not freed in some cases if the
rencache_end_frame was not called when performing the "restart" command.
The invalid access problem can happen because rencache keep some pointers to
FontDesc object but these are Lua userdata that Lua can dispose of. This
situation is prone to hard errors and we should avoid to keep pointers to
objects managed by Lua.
To this purpose we use luaL_ref/unref to bind the FontDesc into the Lua's
registry while rencache need them. We still keeps pointer to FontDesc object but
using luaL_ref we are assured they will not be disposed by Lua.
Since we are using luaL_ref/unref to inform the GC about when the objects are in
use we can now finalize the objects directly when Lua collects them. Previously
the GC metamethods was issuing a FREE command to rencache and the font was
actually freed only from the rencache_end_frame function.
For the option when we use the SDL_Renderer we change:
- the order of calls to SDL_DestroyTexture/Renderer.
Reported by valgrind on linux as an error to destroy the
renderer before the texture.
- the SDL_Renderer and texture are created when the surface is
initialized before the window is shown
It seems that creating the SDL_Renderer and Texture between the
moment the window was shown and the renderer present was introducing
a flashing blank window because of the time taken to create the
renderer/texture resources.
Introduce a new approach that discriminate coordinates in
points and pixels. Now all the logic from the Lua side and in
rencache is to always use points. The coordinates are converted
to pixels only within the renderer, in the file renderer.c.
In this way the application logic does not need to care about the
scaling of the retina displays.
For non-retina display the scaling between points and pixels is
equal to one so nothing will change.
There is nevertheless a change that leak into the Lua side. The
subpixel coordinates are in sub-pixel, not sub-points so they are
scaled by the retina scaling factor. But no change in the code is
required because the subpixel scaling factor take into account the
retina scaling, when present.
Because the retina scaling factor is not know when the application
starts but only when a window is actually available we introduce a
mechanism to render the font with a given scaling factor only from
the renderer when they are needed. We use therefore FontDesc to
describe the font information but without actually rasterizing the
font at a given scale.
The command in rencache.c (Command struct + variable length text) was
incorrectly sized. As a result some bites at the end of the command payload
were uninitialized and was causing hash to randomly change forcing the
system to redraw many more areas.
Since the text of the command for DRAW_TEXT commands is written beginning
at the offset of the text field we compute the bare size of the command as
offsetof(Command, text) instead of sizeof(Command).
Useful to draw whitespaces with alternate characters and colors
without slowing down the text rendering.
A new API is implemented. A renderer.replacements object can be created
to list the replacements.
In turns the function renderer.draw_text and draw_text_subpixel now accept
two optional arguments for replacements.
This reverts commit 461266e97d.
Related to github issue #122.
The void *data field is not used but the glyphset index can
someting be equal to -1 and the unused field prevent faulty
writes before the allocated struct.
In order to fix the issue with cursor positioning a subpixel-aware draw
text operation within rencache was required.
With this modification the cursor positioning problem is completely
resolved.
A new function renderer.draw_text_subpixel is introduced to perform
consecutive, inline, text drawings with subpixel accuracy.
In order to get right the cursor position on text on mouse clicks it is
needed to take into account text's subpixel positioning.
This fix mostly corrects the problem but cursor positioning is still
somewhat inaccurate for long lines due to repeated commands to draw a text
along a line. Repeated draw text calls make the subpixel information
lost and small errors will add-up.
Seen with some fonts like FiraSans, github issue:
https://github.com/franko/lite-xl/issues/46
The fix works essentially by looking to the bounds of each glyph to
accurately ensure that there are no overlaps between the glyphs.
The construction of the font atlas was changed to make some related
improvements now that the bounds of each glyph are know. The main
changes are:
- no longer align glyph on the baseline but align them on their upper
bounds. We ensure this way that very tall fonts do not leak in the
upper part
- terminate the row based on x bounds of the glyph to be more accurate
- for each row keep trace of the y of the more larger along y of the
glyph. The value is used to start a new row to be sure that the new
now does not overlap with the previous one
- sort glyphs by y size before drawing them. In this way the space
utilization is better. The algorithm used is the very simple insert
sort. It behaves like O(n^2) with the number of characters but should
be ok since n is always small, typically below 128.
- compute the optimal image width and height for the given font's atlas
for optimal memory usage. As a bonus now the lite's code don't have to
try and repeat to get a good image size
Add a Meson option "portable" to choose between "portable" and unix-like
directories. Add information about this option in the README.
To determine the user's directory use the variable USERPROFILE only on
Windows and use HOME otherwise.
Implement the "portable" option in the package build script.
Create the user's config init file if lite user's config directory does
not exists.
No longer use the awkward package.searchers but instead add user's
config dir at the end of package path.
It basically works by setting the data directory to
$prefix/share/lite-xl
where $prefix is determined so that $prefix/bin corresponds to EXEDIR.
The packages 'user' and 'user.*' are loaded from the directory
'$HOME/.config/lite-xl'.
The problem was that when the editor had no events the cursor was not
blinking because the event loop was blocking on wait_event.
Now we no longer calls wait_event without a timeout if the windows has
the focus. When the window has the focus the timeout is set to 1 / fps
so that the cursor can blinks.
In addition we react to the "focus lost" event to ensure the documents
are redrawn without the cursor.
Text looks more correct without the gamma correction. With gamma correction
text looks too bold in dark mode and too light in light mode. This
behavior is a sign that gamma correction is not the right thing to do.
The problem is seen with gamma at 1.5 used previously but is even worst
if a gamma value of 2.2, the theoretical value, is used.
Compute Y offset more accurately and the way it is required in
renderer.c.
Instead of returning y offset wrt the baseline position returns it
wrt the top position (the baseline plus the font's ascent).
The purpose it to add later subpixel by storing the bitmap with RGB
channels to have subpixel LCD coverage information.
The colorization and gamma blending will be done when blitting the glyph
on the destination surface.
Now the sizing of fonts is determined by stb_truetype while the
rendering is done via AGG so they are not aligned.
There seems to be an error also about Y text positioning.
Currently the editor will not work if it is not installed.
There is also a caveat about the 'data' directory which is installed
in the bin directory. This may work but does not seem ok because it is
pollution a shared bin directory and the 'data' folder may not be unique
to Lite.