On my system it's slow (because come on, we're talking 550 px at once here), but nowhere near how bad it is for you. On my system it's a bit slow but smooth, so definitely usable, even at that size. (And much bigger problem is the Size slider which is just unbelieveable stubborn :) ).

It might be caused by that 3rd generation CPU, which is a bit old, maybe it doesn't have the CPU vectorization instructions that Krita heavily uses for performance. (Krita, and I believe PS too, doesn't use GPU for calculation, only for showing the end result).

(In reply to Tymond from comment #1)
> On my system it's slow (because come on, we're talking 550 px at once here),
> but nowhere near how bad it is for you. On my system it's a bit slow but
> smooth, so definitely usable, even at that size. (And much bigger problem is
> the Size slider which is just unbelieveable stubborn :) ).
> 
> It might be caused by that 3rd generation CPU, which is a bit old, maybe it
> doesn't have the CPU vectorization instructions that Krita heavily uses for
> performance. (Krita, and I believe PS too, doesn't use GPU for calculation,
> only for showing the end result).

Well, by God's grace, I'll upgrade my hardware in one or two years from now.

*** Bug 441363 has been marked as a duplicate of this bug. ***

@stephen could you please provide:
- as screenshot or in writing: exact setting of the Liquify (like what spacing, what size, what mode etc.)
- an example file (or, if it happens on the empty file too, just size of the canvas + whch color model and profile do you use, if it's not sRGB).

Can confirm on Krita 5 beta3, it is extremely slow on my Windows 10 PC, it takes a very long time to see results of the liquify, the tool most often push the pixels at random it feels like and do not move the pixels around correctly, Krita might even freeze a bit while using the tool. It worked fine in Krita 4.x. This happen on every file. I have a pretty modern 2019 desktop machine, so I think this is affecting a lot of people, I think the bug reports importance should be set much higher than "wishlist"

Here is a video of the problem https://imgur.com/a/iXmBffo

System Info System Info
Krita

 Version: 5.0.0-beta2 (git a642eb0)
 Languages: en_US, en, en_US, en, en_US, en, en_US, en, nn_NO, nn, en_US, en
 Hidpi: true

Qt

  Version (compiled): 5.12.12
  Version (loaded): 5.12.12

OS Information

  Build ABI: x86_64-little_endian-llp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: winnt
  Kernel Version: 10.0.19044
  Pretty Productname: Windows 10 (10.0)
  Product Type: windows
  Product Version: 10

OpenGL Info
 
  Vendor:  "Google Inc." 
  Renderer:  "ANGLE (NVIDIA GeForce RTX 2070 SUPER Direct3D11 vs_5_0 ps_5_0)" 
  Version:  "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" 
  Shading language:  "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" 
  Requested format:  QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
  Current format:  QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) 
     Version: 3.0
     Supports deprecated functions false 
     is OpenGL ES: true 
  supportsBufferMapping: true 
  supportsBufferInvalidation: false 
  Extensions: 
     "GL_EXT_read_format_bgra" 
     "GL_CHROMIUM_copy_compressed_texture" 
     "GL_ANGLE_program_cache_control" 
     "GL_EXT_discard_framebuffer" 
     "GL_EXT_texture_compression_s3tc_srgb" 
     "GL_EXT_texture_rg" 
     "GL_ANGLE_client_arrays" 
     "GL_ANGLE_request_extension" 
     "GL_OES_texture_npot" 
     "GL_ANGLE_texture_usage" 
     "" 
     "GL_EXT_color_buffer_half_float" 
     "GL_OES_mapbuffer" 
     "GL_OES_EGL_image" 
     "GL_EXT_shader_texture_lod" 
     "GL_EXT_texture_format_BGRA8888" 
     "GL_OES_packed_depth_stencil" 
     "GL_EXT_color_buffer_float" 
     "GL_OES_EGL_image_external_essl3" 
     "GL_ANGLE_framebuffer_multisample" 
     "GL_CHROMIUM_sync_query" 
     "GL_OES_compressed_ETC1_RGB8_texture" 
     "GL_ANGLE_texture_compression_dxt3" 
     "GL_EXT_debug_marker" 
     "GL_OES_get_program_binary" 
     "GL_OES_rgb8_rgba8" 
     "GL_CHROMIUM_bind_uniform_location" 
     "GL_ANGLE_translated_shader_source" 
     "GL_CHROMIUM_color_buffer_float_rgba" 
     "GL_OES_surfaceless_context" 
     "GL_EXT_texture_norm16" 
     "GL_NV_EGL_stream_consumer_external" 
     "GL_EXT_frag_depth" 
     "GL_OES_texture_half_float" 
     "GL_ANGLE_pack_reverse_row_order" 
     "GL_ANGLE_depth_texture" 
     "GL_NV_fence" 
     "GL_KHR_debug" 
     "GL_NV_pixel_buffer_object" 
     "GL_ANGLE_multiview" 
     "GL_EXT_texture_storage" 
     "GL_ANGLE_texture_compression_dxt5" 
     "GL_OES_EGL_image_external" 
     "GL_EXT_blend_minmax" 
     "GL_EXT_disjoint_timer_query" 
     "GL_ANGLE_robust_client_memory" 
     "GL_OES_depth32" 
     "GL_OES_vertex_array_object" 
     "GL_ANGLE_lossy_etc_decode" 
     "GL_OES_standard_derivatives" 
     "GL_ANGLE_instanced_arrays" 
     "GL_OES_texture_float" 
     "GL_EXT_sRGB" 
     "GL_NV_pack_subimage" 
     "GL_EXT_occlusion_query_boolean" 
     "GL_CHROMIUM_copy_texture" 
     "GL_EXT_map_buffer_range" 
     "GL_OES_texture_float_linear" 
     "GL_EXT_robustness" 
     "GL_EXT_draw_buffers" 
     "GL_OES_texture_half_float_linear" 
     "GL_CHROMIUM_bind_generates_resource" 
     "GL_CHROMIUM_color_buffer_float_rgb" 
     "GL_EXT_texture_filter_anisotropic" 
     "GL_EXT_texture_compression_dxt1" 
     "GL_EXT_unpack_subimage" 
     "GL_OES_element_index_uint" 
     "GL_ANGLE_framebuffer_blit" 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsAngleD3D11: true 
  isQtPreferAngle: true 

useBufferInvalidation (config option): false


Hardware Information

  GPU Acceleration: auto
  Memory: 40873 Mb
  Number of Cores: 8
  Swap Location: C:/Users/sti-n/AppData/Local/Temp

Current Settings

  Current Swap Location: C:/Users/sti-n/AppData/Local/Temp
  Current Swap Location writable: true
  Undo Enabled: true
  Undo Stack Limit: 100
  Use OpenGL: true
  Use OpenGL Texture Buffer: true
  Disable Vector Optimizations: false
  Disable AVX Optimizations: false
  Canvas State: OPENGL_SUCCESS
  Autosave Interval: 120
  Use Backup Files: true
  Number of Backups Kept: 1
  Backup File Suffix: ~
  Backup Location: Same Folder as the File
  Backup Location writable: false
  Use Win8 Pointer Input: false
  Use RightMiddleTabletButton Workaround: false
  Levels of Detail Enabled: false
  Use Zip64: false


Display Information
Number of screens: 3
	Screen: 0
		Name: \\.\DISPLAY1
		Depth: 32
		Scale: 1
		Resolution in pixels: 2560x1440
		Manufacturer: 
		Model: 
		Refresh Rate: 144
	Screen: 1
		Name: \\.\DISPLAY2
		Depth: 32
		Scale: 1
		Resolution in pixels: 1920x1080
		Manufacturer: 
		Model: 
		Refresh Rate: 60
	Screen: 2
		Name: \\.\DISPLAY3
		Depth: 32
		Scale: 1
		Resolution in pixels: 1920x1080
		Manufacturer: 
		Model: 
		Refresh Rate: 60

Hi, 
I guess these bugs report of @Stig (Rakurri) , @holtein and @Stephen happens because of a more fundamental change of default in the 5x transform tool: the new default 'in stack rendering'  that is − indeed− super slow (especially in liquify, especially on recursive groups in liquify too). I had same issue once I started to adopt 5.x.

Can you try to go to the "tool options" panel after selecting the "transform tool", and turn the "Preview" setting (on top) to "Fast"? 
Does it restore the speed you knew on 4.x ? (it should, "Fast" was the setting by default in 4.x)

(Sorry for the late reply, have been very occupied with exams.) It seems to work about the same on fast in both versions. I noticed though that my spacing was very high. And when the spacing is high I notice that the liquify seems to push the pixels in the wrong way the first dab(s) a lot of the time. This to me made it look much less performant. Is that effect visible in the videos I sent? It makes the liquify much less usable on high spacing, although it is not noticeable on low spacing

(In reply to Stig (Rakurri) from comment #7)
> (Sorry for the late reply, have been very occupied with exams.) It seems to
> work about the same on fast in both versions. I noticed though that my
> spacing was very high. And when the spacing is high I notice that the
> liquify seems to push the pixels in the wrong way the first dab(s) a lot of
> the time. This to me made it look much less performant. Is that effect
> visible in the videos I sent? It makes the liquify much less usable on high
> spacing, although it is not noticeable on low spacing
This happens for both 4.4.8 and 5 beta3

So what is the conclusion - when using "Fast" preview in Krita 5., is it much slower than Krita 4., or around the same speed (no mater if very slow on higher spacing)? Asking to be sure whether there has been any regression, or is it just a normal (albeit slow) performance and this report is a wish for Liquify to go faster.

Hey Tiar, the fast mode option is as fast in 5.x as it was in 4.x. 
No regression here. 

The slow one is the "new" preview mode that appeared for 5.x and was made the default.

But this last one has "in layer stack rendering", a cool feature over the "fast mode". 

Unfortunately, Liquify is very laggy and unusable in this new 5.x default mode. I personnaly set performance to 'Fast' right after Krita 5.x because I know my way in Tool Options[1] and never looked back.